async

[Eh2406]

There are use cases where getting the available versions and the dependencies for a version require async operations like network requests. cc rust-lang/cargo#8890 and npm api.

We should make sure that this is doable with the dependency_provider trait before 1.0.
I discussed this problem with @jonhoo. It is possible to make it work with the existing (0.2) api. This involves having the implementer store a pointer to the runtime in its new method. This allows choose_package_version to spawn new request for packages in potential_packages that are not yet in flight, then block on a FuturesUnordered of all of them.

How ergonomic is this? Do we need a helper function so that all implementers don't have to make it up themselves? Do we need to redesign the API to be async aware? We won't know until someone tries it.

[mpizenberg]

Good point! Is it correct that right now every async usage of Rust also have a blocking sync equivalent? like for network everything also exists with blocking APIs I think. We don't want to force users on one path for version 1.0 though.

Otherwise performance-wise everything happening within the resolver, except calls to the dependency provider is pure computation with no IO, so I don't think it would be worth introducing async in the API. I've never used async before but if there is a way to wait on termination of a bunch of async calls within a sync function (that has a reference to an async runtime), it's maybe better to have API appearing as classic non-async, but implementer can use whatever within the function call.

[Eh2406]

I personally agree with you. If we can make an example that uses async internally but uses the current api that would make me happy. This is mostly a reminder to give it a try at some point.

The think that async makes ergonomic that is somewhat painful with blocking is requesting a bunch of things at the same time. Http pipelining means that 100 requests can have basically the same total time as 1 request. Can you do that without the async keyword, absolutely but it is not simple.