-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async API? #110
Comments
Thank you for giving this a try! I look forward to reading over your elm example! It is related to pubgrub-rs/advanced_dependency_providers#6. The first problem is that we don't fit well into the "just create futures and process them when they're done" paradigm. While What I had in mind was:
Of course this may fall apart when we actually try and implement it. |
CC #138 |
In uv, we moved to running pubgrub in a separate, dedicated thread (astral-sh/uv#3627) and the single threaded tokio runtime as main thread (astral-sh/uv#4934), which are faster for us. |
I've been playing with making a WebAssembly solver for the Elm ecosystem, with the aim of it being easily usable for tooling written in JavaScript. The wasm API I've settled on for the time being looks like this:
It works fine but requires that the
fetchDependencies
andlistVersions
functions passed as argument are sync. However, in the NodeJS ecosystem, reading files and making http requests is mainly done with async. So this API forces the user to use sync versions of file IO, which is fine, and sync versions of http requests which is a bit more annoying to do.In order to be able to write those two functions with async, it means we also need an async version of the
DependencyProvider
trait, wheregetDependencies
andchoosePackageVersion
would return futures instead of normal values. I'm not sure if it's easily done, because async and traits are quite painful together from some of my readings, but I wanted to raise this use case.The text was updated successfully, but these errors were encountered: