pipenv icon indicating copy to clipboard operation
pipenv copied to clipboard

Accelerate build times by using uv instead of pip?

Open cclauss opened this issue 1 year ago • 6 comments

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.

cclauss avatar Mar 11 '24 10:03 cclauss

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.

matteius avatar Mar 21 '24 22:03 matteius

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.

cclauss avatar Mar 21 '24 22:03 cclauss

+1 for supporting uv

anoother avatar May 21 '24 10:05 anoother

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.

thernstig avatar Sep 07 '24 16:09 thernstig

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

connorhsm avatar Sep 08 '24 23:09 connorhsm

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.

cclauss avatar Sep 09 '24 09:09 cclauss