Uv is fantastic, but its package management UX is a mess • Hacker News Board

Re: Uv is fantastic, but its package management UX is a mess

#31

Post by saghm » Fri, May 22, 2026, 12:55 AM UTC

wrs wrote: post #5

the_mitsuhiko wrote: post #3

> Note the lack of an upper bound Since uv needs a singular resolution that's entirely intentional. In npm you can install diverging resolutions for different parts of the tree but that is not an option with Python. I had to make the same decision in Rye and there is just no better solution here. If an upper bound were to be supplied you would end up with trees that can no longer resolve in practice. Some package eco…

The entire purpose of semver is to give you a way to resolve that conundrum. New major version = assume it's incompatible. I mean, it may not actually work , but that's what it's for.

> The entire purpose of semver is to give you a way to resolve that conundrum. New major version = assume it's incompatible.

I'm not sure I'd agree with that characterization. The point of semver is that you can assume that certain types of bumps won't include certain types of changes, not that you assume that the types of changes that can happen in a type of bump will happen. A major version bump not breaking anything is completely valid semver, and breaking one function (which plenty of users might not use, or might use in a way that doesn't get broken) in an API with thousands is still technically only valid in a major version bump (outside of specific exceptions like the major version being 0).

It's a subtle difference, and I'm optimistic that it's something you understand, but misunderstandings of semver seem so common that I can't help but feel like precision when discussing it is important. I've encountered so many smart people who misunderstand aspects of semver (and not just minutia like "what constraints are there on tags after the version numbers"), and almost all of them seemed to have stemmed from people learning a few of basic tenets of it and inferring how to fill in the large gaps in a way that isn't at all how its specified. The semver specification is pretty clear in my opinion even about where some of the edge cases someone less informed might assume, and if we don't agree on that as the definition, I don't know how we avoid the (completely realistic) scenario where everyone in the room has an idea of what "semver" means that's maybe 80% compatible with the spec, but the 80% is different for each of them, and trying to resolve disagreements when people don't agree about what words mean is really hard.

Re: Uv is fantastic, but its package management UX is a mess

#32

Post by jim33442 » Fri, May 22, 2026, 12:57 AM UTC

jimbokun wrote: post #28

> Poetry does the same by default, using a format like >=1.23.4, What??? I understood the first format instantly, but had no idea what the second meant until the author explained it.

I saw that ^ so many times in npm and never knew what it meant until now

Re: Uv is fantastic, but its package management UX is a mess

#33

Post by kjmr » Fri, May 22, 2026, 12:57 AM UTC

woodruffw wrote: post #15

(Note: I work on uv.) Much of this is useful feedback, even if phrased in a clickbait style. Some thoughts: - Re: `pnpm outdated`: this is something that hasn't come up very much, even though it seems reasonable to me. I suspect this comes down to cultural differences between Python and JavaScript -- I can't think of a time when I've cared about whether my Python dependencies were outdated, so long as they weren't vu…

Author of the article here. Sorry it comes across as “clickbait style” when actually it’s simply Dutch bluntness and honesty

poetry update also updates the lockfile. I really think the way the uv cli is organized makes it quite annoying to work with. It’s designed for correctness, for machines, not for user-friendliness.

Re: Uv is fantastic, but its package management UX is a mess

#34

Post by thayne » Fri, May 22, 2026, 12:58 AM UTC

the_mitsuhiko wrote: post #3

> Note the lack of an upper bound Since uv needs a singular resolution that's entirely intentional. In npm you can install diverging resolutions for different parts of the tree but that is not an option with Python. I had to make the same decision in Rye and there is just no better solution here. If an upper bound were to be supplied you would end up with trees that can no longer resolve in practice. Some package eco…

Personally, I'd rather get an error from uv that packages aren't compatible when I run update, with a way to override that if needed, than get an error at runtime that may be difficult to track down to incompatible versions.

Re: Uv is fantastic, but its package management UX is a mess

#35

Post by saghm » Fri, May 22, 2026, 1:02 AM UTC

jimbokun wrote: post #28

> Poetry does the same by default, using a format like >=1.23.4, What??? I understood the first format instantly, but had no idea what the second meant until the author explained it.

I don't know if there's a good source for where this convention started but it's not that uncommon; offhand, both npm[1] and Cargo[2] support that format.

[1]: https://docs.npmjs.com/about-semantic-versioning#using-seman... [2]: https://doc.rust-lang.org/cargo/reference/specifying-depende...

Re: Uv is fantastic, but its package management UX is a mess

#36

Post by jim33442 » Fri, May 22, 2026, 1:05 AM UTC

On it being a "mess": When writing applications, I only devoted at most 2 brain cells to installing dependencies even before Claude existed, and that was enough for npm, uv, or cargo to just work. Never used any of these flags. Meanwhile pip etc demand way more attention to not ruin things.

Re: Uv is fantastic, but its package management UX is a mess

#37

Post by foobarbecue » Fri, May 22, 2026, 1:05 AM UTC

jim33442 wrote: post #23

daemonologist wrote: post #16

Earlier quoted context omitted.

uv has a lot of great features, but the dependency resolution is why I'm a fanboy. It can resolve trees that pip gives up on, and it does it 20x faster than poetry (100x faster than pip) - saves me half an hour on some big projects. All the python resolution and environment management and stuff is just gravy.

Yeah, this is when it really matters that they wrote it in a CPU-performant language. There have been times I pointed uv at a random pip-managed GitHub project to rescue it because the author forgot to specify some versions and entire deps in requirements.txt. It even took uv a bit of chugging to find an overlap. Also wow, those packages had a lot of pointless breaking changes.

Rust isn't the main reason it's fast. The main reason is willingness to break backwards compatibility. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Re: Uv is fantastic, but its package management UX is a mess

#38

Post by elyobo » Fri, May 22, 2026, 1:09 AM UTC

jim33442 wrote: post #9

the_mitsuhiko wrote: post #3

> Note the lack of an upper bound Since uv needs a singular resolution that's entirely intentional. In npm you can install diverging resolutions for different parts of the tree but that is not an option with Python. I had to make the same decision in Rye and there is just no better solution here. If an upper bound were to be supplied you would end up with trees that can no longer resolve in practice. Some package eco…

Also it doesn't even matter because the real way to use both uv and npm is to switch everything to = and only update manually, rather than trusting non-major updates not to break anything

non major updates in the npm ecosystem are pretty reliable in my experience; my much more limited python experience suggests that semver is much less respected on that side of the fence

Re: Uv is fantastic, but its package management UX is a mess

#39

Post by saghm » Fri, May 22, 2026, 1:10 AM UTC

jim33442 wrote: post #23

daemonologist wrote: post #16

Earlier quoted context omitted.

uv has a lot of great features, but the dependency resolution is why I'm a fanboy. It can resolve trees that pip gives up on, and it does it 20x faster than poetry (100x faster than pip) - saves me half an hour on some big projects. All the python resolution and environment management and stuff is just gravy.

Yeah, this is when it really matters that they wrote it in a CPU-performant language. There have been times I pointed uv at a random pip-managed GitHub project to rescue it because the author forgot to specify some versions and entire deps in requirements.txt. It even took uv a bit of chugging to find an overlap. Also wow, those packages had a lot of pointless breaking changes.

I don't do Python all that often, but I got sold on uv when a year or so ago I wanted to try to fix a small bug in a relatively niche Python open source I was trying to use, and it used a packaging tool I hadn't even heard of before (pdm). I was able to run `uv tool run pdm ` without having to know anything about how pdm worked or worry about how to properly install yet another python tool and figure out whether I needed to be concerned about whether it might try to use system (or user local) versions of packages I had installed or get pointed at a magic hidden directory that I had to create first. When I realized I might never have to care about that ever again for any Python tool, I was hooked.

Re: Uv is fantastic, but its package management UX is a mess

#40

Post by woodruffw » Fri, May 22, 2026, 1:10 AM UTC

strangelove026 wrote: post #21

UV has done so much for Python but I did fight it a bit today. I was trying to centralize the management of a script that appears in a few different repos, and has invariably drifted in its implementation in multiple way over time. My idea was uv run --with $package main --help I was looking for an easy way to automatically 1. Install it if it doesn’t exist and run 2. Don’t install it if it’s running the latest versi…

I think you want `uv tool install` and `uv tool upgrade` for that. But also: please file an issue, because it sounds like the kind of papercut we could address somewhat easily!