#is there a preferred dedicated way to

1 messages · Page 1 of 1 (latest)

real lynx
#

I think that's the only way to do it currently. I'd be interested to hear about your use case, but it sounds like you probably want an API that you can provide multiple project names in a single request and get back results for all of them. Those kinds of APIs are hard for us to cache efficiently, so in terms of wastefulness, we actually generally prefer APIs like the existing one where you make 100 per-project requests instead.

quick ivy
#

my use case is basically poetry update: i have a cache and lockfile and i want to check if any packages can be updated

#

but it maskes sense that 100 request that fastly has cached away doesn't even need to deliver any data for are easier on warehouse

real lynx
#

So, one thing I can imagine is a hypothetical API where you provide a project name (and probably some packaging tags) and get back the equivalent of a fully resolved lockfile for that project and all it's dependencies, with the latest hashes for files. It's not exactly possible today and would require quite a bit of work to implement correctly, but it'd probably be much easier to cache.

#

I'm not sure it would exactly work for your use-case though, because there would still need to be some resolution between top-level dependencies in the case that they have mutually incompatible sub-dependencies.

quick ivy
#

a slightly different api would be great: you query a package and you get the last change date (or etag or something) for its direct and all transitive dependencies. this way we'd need to make one request per direct dependency and in the best case everything we need, in a weird backtracking case it's maybe a handful extra requests

#

(the problem with the lockfile is that if e.g. 2.0.0 is in the lockfile but have 1.0.0 resolved because 2.0.0 was incompatible you still don't know about the 1.0.1 bugfix release)