Accelerate build times by using uv instead of pip?

[cclauss]

There is a lot of discussion about the Rust-based pip-replacement named uv.

• https://astral.sh/blog/uv
• https://github.com/astral-sh/uv/blob/main/README.md

Would it be of interest to accelerate pipenv build times by using uv instead of pip?

Is your feature request related to a problem? Please describe.

I'm always frustrated when pipenv builds take several minutes.

Describe the solution you'd like

pipenv builds take seconds instead of minutes.

Describe alternatives you've considered

Switch to non-pipenv solutions for our builds.

[matteius]

I am stuck on the philosophical questions of: would we need to rebrand to uvenv? maybe it should be a whole new project -- but is it realistically much faster when most things are network activity of getting the wheels, and then they still need to be installed? In all seriousness though, it might be worth me taking a deeper look, but we have to admit that pipenv is a big bear hug around pip and so there is a lot to detangle there if there were a motivation to wrap a different package library.

[cclauss]

The caching in uv is super impressive. The first build is lightning fast but the second is astonishing especially on a huge set of deps.

[anoother]

+1 for supporting uv

[thernstig]

It's been a good ride, but uv has far surpassed pipenv. Unfortunately this is what historically happens to open source software projects, something evolutionary comes along and kills old solutions.

[connorhsm]

uv is still pre v1.0, but since August 20 has fully replaced my Pipenv workflow with the implementation of their lock file.
https://astral.sh/blog/uv-unified-python-packaging

[cclauss]

Languages like Go and Rust have quite a different approach to reaching v1.0 than Python does. Once a package has reached v1.0 in these languages it is kind of a commitment to Never break backward compatibility. There is no such commitment w/ Python packages.

[FlavioAmurrioCS]

I made POC pipenv-uv, a package that monkey patches pipenv's resolver and installer with uv's. @matteius would having uv be an alternative resolver be a feature you would consider.

github.com/FlavioAmurrioCS/pipenv-uv

Inspiration: https://pypi.org/project/pre-commit-uv/

[matteius]

@FlavioAmurrioCS actually yes, I would -- it was something I was thinking about a couple months back, but it could not repalce -- serve as an alternative, I may have branch floating around somewhere too. Problem is I won't have time to look into this specifically for a bit. I do hope to vendor in latest pip and do a few other updates soon, but this is a much bigger change.

See my priror research: https://github.com/pypa/pipenv/pull/new/uv-backend

[FlavioAmurrioCS]

Cool! I have gotten pretty close to parity with original pipenv functionality since I still wanted to keep Pipfile.lock and have people/CI using old pipenv to still work. For my approach I use uv pip compile to resolve into a requirements.txt and I was parsing that (this was before pylock.toml). I'll check if I can move pylock.toml to make it easier. I'll fork, patch, see if all test pass and then move to a proper implementation.

[FlavioAmurrioCS]

Update, I have a POC working. Will give it to some coworkers to test it out before making the PR.

[matteius]

Update on this?