Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv overtakes pip in CI

wagtail.org

Post reply on HN
Print view View original

51–60 of 184 posts

Re: Uv overtakes pip in CI

#51

Post by cgearhart »

torben-friis wrote: post #10

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 ?

BDFL left a long time ago. It’s not opinionated anymore. The language went from being small enough to fit in that guy’s head to a language controlled by committee that’s trying to please everyone.

Re: Uv overtakes pip in CI

#52

Post by morshu9001 »

torben-friis wrote: post #10

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 was an intentional design decision to separate package installation and management. I think that created the mess we have now.

Funny thing is that decision was for modularity, but uv didn't even reuse pip.

Re: Uv overtakes pip in CI

#53

Post by morshu9001 »

lvl155 wrote: post #16
torben-friis wrote: post #10

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 ?

I call it the JS-syndrome.

JS did this right, in fact uv is kinda replicating the npm way. And there are other JS things I'd like Py to follow suit on.

Re: Uv overtakes pip in CI

#54

Post by eslaught »

andy99 wrote: post #40
bognition wrote: post #3

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.

I’ll bite - I could care less about speed, that feels like a talking point I see often repeated despite other package managers not being particularly slow. Maybe there’s some workload I’m missing that this is more important for? I’ve tried uv a couple places where it’s been forced on me, and it didn’t work for whatever reason. I know thats anecdotal and I’m sure it mostly works, but it obviously was off putting. For…

Conda doesn't do lock files. If you look into it, the best you can do is freeze your entire environment. Aside from this being an entirely manual process, and thus having all the issues that manual processes bring, this comes with a few issues:

1. If you edit any dependency, you resolve the environment from scratch. There is no way to update just one dependency.

2. Conda "lock" files are just the hashes of the all the packages you happened to get, and that means they're non-portable. If you move from x86 to ARM, or Mac to Linux, or CPU to GPU, you have to throw everything out and resolve.

Point (2) has an additional hidden cost: unless you go massively out of your way, all your platforms can end up on different versions. That's because solving every environment is a manual process and it's unlikely you're taking the time to run through 6+ different options all at once. So if different users solve the environments on different days from the same human-readable environment file, there's no reason to expect them to be in sync. They'll slowly diverge over time and you'll start to see breakage because the versions diverge.

P.S. if you do want a "uv for Conda packages", see Pixi [1], which has a lot of the benefits of uv (e.g., lock files) but works out of the box with Conda's package ecosystem.

[1]: https://pixi.sh/latest/

Re: Uv overtakes pip in CI

#55

Post by nicwolff »

gatvol wrote: 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).

    ENV UV_SYSTEM_PYTHON=1

Re: Uv overtakes pip in CI

#56

Post by swyx »

cgearhart wrote: post #51
torben-friis wrote: post #10

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 ?

BDFL left a long time ago. It’s not opinionated anymore. The language went from being small enough to fit in that guy’s head to a language controlled by committee that’s trying to please everyone.

poor answer. guido had very little impact on the packaging mess.

Re: Uv overtakes pip in CI

#57

Post by simonw »

andy99 wrote: post #40
bognition wrote: post #3

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.

I’ll bite - I could care less about speed, that feels like a talking point I see often repeated despite other package managers not being particularly slow. Maybe there’s some workload I’m missing that this is more important for? I’ve tried uv a couple places where it’s been forced on me, and it didn’t work for whatever reason. I know thats anecdotal and I’m sure it mostly works, but it obviously was off putting. For…

The place where speed really matters is in virtual environment management.

uv uses some very neat tricks involving hard links such that if you start a new uv-managed virtual environment and install packages into it that you've used previously, the packages are symlinked in. This means the new environment becomes usable almost instantly and you don't end up wasting filesystem space on a bunch of duplicate files.

This means it's no longer expensive to have dozens, hundreds or even thousands of environments on a machine. This is fantastic for people like myself who work on a lot of different projects at once.

Then you can use "uv run" to run Python code in a brand new temporary environment that get created on-demand within ms of you launching it.

I wrote a Bash script the other day that lets me do this in any Python project directory that includes a setup.py or pyproject.toml file:

  uv-test -p 3.11
That will run pytest with Python 3.11 (or 3.12/3.13/3.14/whatever version you like) against the current project, in a fresh isolated environment, without any risk of conflicting with anything else. And it's fast - the overhead of that environment setup is negligible.

Which means I can test any code I like against different Python versions without any extra steps.

https://til.simonwillison.net/python/uv-tests

Re: Uv overtakes pip in CI

#58

Post by zahlman »

mikepurvis wrote: post #33
torben-friis wrote: post #10

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 ?

Python 2.0 was released in October 2000. The Python ecosystem has witnessed several significant shifts in expectation as far as how software is built and delivered, from Slackware-style source builds to vendor packages to containers to uv just downloading a standalone binary archive. And the deadsnakes ppa and venvs, plus the ongoing awkwardness about whether pip should be writing stuff into usr/local or ~/.local or…

> the deadsnakes ppa

Please don't use this. You need to be careful about how you place any secondary installation of Python on Ubuntu. Meanwhile, it's easy to build from source on Ubuntu and you can easily control its destination this way (by setting a prefix when you ./configure, and using make altinstall) and keep it out of Apt's way.

> and venvs, plus the ongoing awkwardness about whether pip should be writing stuff into usr/local or ~/.local or something else.

There is not really anything like this. You just use venvs now, which should have already been the rule since 3.3. If you need to put the package in the system environment, use an Apt package for that. If there isn't an Apt package for what you want, it shouldn't live in the system environment and also shouldn't live in your "user" site-packages — because that can still cause problems for system tools written in Python, including Apt.

You only need to think about venvs as the destination, and venvs are easy to understand (and are also fundamental to how uv works). Start with https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... .

> It’s really only in the last ten years or so that there’s been the clarity of what is a build backend vs frontend

Well no; it's in that time that the idea of separating a backend and frontend emerged. Before that, it was assumed that Setuptools could just do everything. But it really couldn't, and it also led to people distributing source packages for pure-Python projects, resulting in installation doing a ton of ultimately useless work. And now that Setuptools is supposed to be focused on providing a build backend, it's mostly dead code in that workflow, but they still can't get rid of it for backwards compatibility reasons.

(Incidentally, uv's provided backend only supports pure Python — they're currently recommending heavyweight tools like maturin and scikit-build-core if you need to compile something. Although in principle you can use Setuptools if you want.)

Re: Uv overtakes pip in CI

#59

Post by testdelacc1 »

falcor84 wrote: post #31
simonw wrote: post #22

Earlier quoted context omitted.

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…

On a tangent, the somewhat related issue of Python 3 not being able to import Python 2 packages famously led Zed Shaw of "Learn Python the Hard Way" to write a rant about how Python is not Turing Complete. I checked again and apparently he removed that rant and only has a disclaimer in its place mentioning that he was obviously being hyperbolic [0]. [0] https://learnpythonthehardway.org/book/nopython3.html#the-py...

I don’t think anyone takes Zed Shaw seriously.

He’s like that uncle you see at family gatherings whom you nod along politely to.

Re: Uv overtakes pip in CI

#60

Post by zahlman »

morshu9001 wrote: post #52
torben-friis wrote: post #10

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 was an intentional design decision to separate package installation and management. I think that created the mess we have now. Funny thing is that decision was for modularity, but uv didn't even reuse pip.

> Funny thing is that decision was for modularity, but uv didn't even reuse pip.

To be fair, that's justified by pip's overall lack of good design. Which in turn is justified by its long, organic development (I'm not trying to slight the maintainers here).

But I'm making modular pieces that I hope will showcase the original idea properly. Starting with an installer, PAPER, and build backend, bbbb. These work together with `build` and `twine` (already provided by PyPA) to do the important core tasks of packaging and distribution. I'm not trying to make a "project manager", but I do plan to support PEP 751 lockfiles.

Post reply on HN