Live data from Hacker News

Uv overtakes pip in CI

wagtail.org

21–30 of 184 posts

Re: Uv overtakes pip in CI

#21
post #9

This shouldn’t be a surprise to anyone who has been using Python and has tried uv. Python dependency management and environments have been a pain for 15 years. Poetry was nice but slow and sometimes difficult. Uv is lightning fast and damn easy to use. It’s so functional and simple.

for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more

I think it’s been long enough now. Uv just has so much velocity. Pyproject.toml and pep support just keeps getting better.

Poetry which I think is the closest analogue, still requires a [tool.poetry.depenencies] section afaik.

Re: Uv overtakes pip in CI

#22

As an outsider to python, I never got how a language who got popular for being simple, elegant and readable could end up with perhaps the most complex tooling situation (dependencies, envs, etc). Any time I glance at the community there seems to be a new way of doing things. What caused python to go through these issues? Is there any fundamental design flaw ?

It's mostly about age. Python has been around for 35 years now. The first version of a Python package directory was the cheeseshop (Monthy Python reference) in 2003. The earliest version of a pip-like tool was "easy_install" which - I kid you not - worked by scraping the HTML listing page of the cheeseshop and downloading zip files linked from that!

More recent languages like Node.js and Rust and Go all got to create their packaging ecosystems learning from the experiences of Perl and Python before them.

There is one part of Python that I consider a design flaw when it comes to packaging: the sys.modules global dictionary means it's not at all easy in Python to install two versions of the same package at the same time. This makes it really tricky if you have dependency A and dependency B both of which themselves require different versions of dependency C.

Re: Uv overtakes pip in CI

#23
post #7
post #5

Earlier quoted context omitted.

Why not use a virtualenv in your container?

This is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for muc…

I'm intrigued. I've been using virtualenv in numerous companies for about 8 years, traditionally wrapped in virtualenvwrappers, and now in uv.

UV doesn't change any of that for me - it just wraps virtualenv and pip downloads dependencies (much, much) more quickly - the conversion was immediate and required zero changes.

UV is a pip / virtualenv wrapper. And It's a phenomenal wrapper - absolutely changed everything about how I do development - but under the hood it's still just virtualenv + pip - nothing changed there.

Can you expand on the pain you've experienced?

Regarding "things that need to be deployed" - internally all our repos have standardized on direnv (and in some really advanced environments, nix + direnv, but direnv alone does the trick 90% of the time) - so you just "cd ", direnv executes your virtualenv and you are good to go. UV takes care of the pip work.

Has eliminated 100% use of virtualenvwrappers and direct-calls to pip. I'd love to hear a use case where that doesn't work for you - we haven't tripped across it recently.

Re: Uv overtakes pip in CI

#24
post #9

This shouldn’t be a surprise to anyone who has been using Python and has tried uv. Python dependency management and environments have been a pain for 15 years. Poetry was nice but slow and sometimes difficult. Uv is lightning fast and damn easy to use. It’s so functional and simple.

for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more

uv having a good pip compatibility layer probably helped a lot, because you could try things out that way and see what fit, so to speak.

It's probably worth mentioning that Astral (The team behind uv/etc) has a team filled with people with a history of making very good CLI tooling. They probably have a very good sense for what matters in this stuff, and are thus avoiding a lot of pain.

Motivation is not enough, there's also a skill factor. And being multiple people working on it "full time"-ish means you can get so much done, especially before the backwards compat issues really start falling into place

Re: Uv overtakes pip in CI

#25
post #9

This shouldn’t be a surprise to anyone who has been using Python and has tried uv. Python dependency management and environments have been a pain for 15 years. Poetry was nice but slow and sometimes difficult. Uv is lightning fast and damn easy to use. It’s so functional and simple.

for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more

The pace of uv adoption is insanely fast. It's directly related to how bad the previous Python tools were/are. Even to seasoned veterans set in their ways - they still know a better solution when they see it.

Re: Uv overtakes pip in CI

#27
post #4

UV is super fast and great for environment management, however it's not at all well suited to a containerised environment, unless I'm missing something fundamental (unless you like using an env in your container that is).

> (unless you like using an env in your container that is).

What's the problem with that?

You just make your script's entry point be something like this:

    uv venv --clear
    uv sync
    uv run main.py

Re: Uv overtakes pip in CI

#28

As an outsider to python, I never got how a language who got popular for being simple, elegant and readable could end up with perhaps the most complex tooling situation (dependencies, envs, etc). Any time I glance at the community there seems to be a new way of doing things. What caused python to go through these issues? Is there any fundamental design flaw ?

If you read the initial bbs post by Guido introducing Python he describes it mostly as an alternative to bash. Basically a really nice scripting language with a decent standard library. I don’t think it was designed from the start to end up where it has. He created a genius syntax that people love.

Re: Uv overtakes pip in CI

#29
post #9

Earlier quoted context omitted.

for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more

Honestly, I was skeptical when I learned about uv. I thought, just Python needs, another dependency manager… this was after fighting with pip, venv, venvwrapper, and poetry for years. Then I gave it a try and it just worked! It’s so much better that I immediately moved all my Python projects to it.

> I thought, just Python needs, another dependency manager… this was after fighting with pip, venv, venvwrapper, and poetry for years.

Pip, venv and virtualenvwrapper (people still use this?) are not meaningfully "dependency managers". A venv is just a place to put things, and pip does only basic tracking and tries to maintain a consistent environment. It isn't trying to help you figure out what dependencies you need, create new environments from scratch, update pyproject.toml....

Pip's core capability is the actual installation of packages, and uv does a far better job of that part, using smarter caching, hard links to share files, parallelized pre-compilation of .pyc files, etc. Basically it's designed from the ground up with the intention to make lots of environments and expect starting a new one to be cheap. Poetry, as far as I was able to determine, does it basically the same way as pip.

Re: Uv overtakes pip in CI

#30
post #15

Earlier quoted context omitted.

I haven’t really had this issue. UV’s recommendation is to mount the uv.lock and install those manages package versions to the container’s global pip environment. We haven’t had much issue at my work, where we use this to auto-manage python developer’s execution environments at scale.

> UV’s recommendation is to mount the uv.lock and install those manages package versions to the container’s global pip environment. Source? That's an option, but it's not even explicitly mentioned in the related documentation [1]. [1] https://docs.astral.sh/uv/guides/integration/docker/

https://docs.astral.sh/uv/guides/integration/docker/#interme...

You kind of have to read between the lines and "know" this is a good solution and then when you see it it's like "right of course".

Post reply on HN