-
-
Notifications
You must be signed in to change notification settings - Fork 255
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
Consider using uv as an optional alternate resolver. #2371
Comments
Yeah, saw that. It won't be useable for It's also nominally 3.8+. The existing PipVersion infra does handle ranges of Python Pip works for though; so that bump should be handleable. Honestly though, if they achieve their vision and it remains Apache 2 / MIT, Pex should ~die and perhaps only live on as a package format uv produces. When I get a chance I always lobby Python / PyPA for 1 true tool, and that is what uv may become. |
Maybe by the time the uv rise to the one true tool comes to pass - which is insane - Your language's tool in another language becuase yours is too damn slow - Mojo will have killed off Python! Hah. |
Maybe Python becomes an intermediate scripting language that GenAI transpiles to Rust. |
Lots of people reacting to this - I'm going to assume that means folks agree Python / Pip / Pex are too slow right now and there is demand for the fast uv offers. If so, and you're feeling lock resolve pain, this has been hanging there for a long time now:
That's probably fairly involved, but if any one wants to dive in, that'd be great. I'm a bit async depending on climbing, but I'm happy to answer questions, review PRs, etc. On the slow PEX build end, which is mainly for larger PEX zips, there is the relatively recent Pex support for As to other pain points related to speed, I may have lost track and would certainly appreciate folks speaking up here. I could then organize and break out issues for any problems that seem solvable. |
One thing that struck me is most folks are probably ignorant of pip |
Ok, the |
|
As per #2210, |
I'm also interested in adapting |
Chiming in: After seeing It's too early to understand exactly where things will end up, but there is a decent chance that if In light on this, I think it would make sense for pants to lean into the zeitgeist, and embrace seamless |
Thanks for the input @BrendanJM ! This ticket is specifically about Pex adopting uv, which would be one way Pants could do so, but not the only way. I've just reopened pantsbuild/pants#20679 to discuss Pants using uv directly. Since your post references Pants, that might be a good place to cross-post it. |
Doh… I followed this issue from the pants issue, didn’t realize I ended up in a different project 🫠 |
FWIW, |
@astrojuanlu that's good to know, however not enough. I want to be clear. If someone wants to contribute support they are free to try, but there are many features Pex needs to continue to support (it never breaks existing users), including lock subsetting, |
If having Pex use UV is opt-in and does not become the new default, having it not support various options from the start is not a breaking change. Adding support for UV in Pex incrementally is an option thus, no? |
Yes, but I think no one here has any clue what that actually means. I would love someone to step up and wrestle with how much special case code they do or do not need to make this happen. I won't be getting to it personally for quite some time. There are many other items to chew through. |
uv is a new resolver and installer written in Rust. It claims to be substantially faster than Pip at resolving (and installing, although that is less relevant to us). It also claims to expose a CLI interface compatible with
pip
, so it supposedly can be used as a drop-in replacement. It notably does not claim to generate the same resolves as Pip (it uses PubGrub as the underlying solver).See https://astral.sh/blog/uv for more.
uv makes some weighty claims, but we know from experience that the Python packaging ecosystem is messy, with many edge cases, ad-hoc behaviors, sharp edges, and de-facto standards that are not codified anywhere. It's as yet unclear how truly functional, or pip-compatible, uv is in real-world cases. So uv still requires substantial vetting by the community.
This ticket is to track and discuss the idea of embedding uv in Pex as an optional alternate resolver. We can evaluate potential benefits and drawbacks as uv gets more real-world usage, and if we see practical performance gains, before committing any effort to this.
The text was updated successfully, but these errors were encountered: