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

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

loopwerk.io

Post reply on HN
Print view View original

11–20 of 161 posts

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

#11

Post by galangalalgol »

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

Isn't there a lock file for that? I'm mostly a rust dev, but I thought I saw a lock file in a uv project I was vibe coding

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

#12

Post by KlayLay »

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.

Semantic versioning is about versioning individual dependencies, no? The issue here seems to be about transitive dependencies, where different versions of the same package is used by multiple packages which depend on it.

uv's default being to always select the latest version seems to be what Clojure's tools.deps does.

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

#13

Post by chippiewill »

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.

There isn't a good way to know if a given package is using semver though.

There's a lot of packages in the Python ecosystem that use time based versioning rather than semver (literally `year.minor`) and closed ranges cause untold problems.

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

#14

Post by chippiewill »

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

But that's why you have a lockfile?

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

#15

Post by woodruffw »

(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 vulnerable or broken. By contrast, it appears to be somewhat common in the JavaScript ecosystem to upgrade opportunistically. I don't think this is bad per se, but seems to me like a good demonstration of discontinuous intuitions around what's valuable to surface in a CLI between very large programming communities.

- As Armin notes[1], uv's upper bound behavior is intentional (and is a functional necessity of how Python resolution works at large). This is a tradeoff Python makes versus other languages, but I frankly think it's a good one: I like having one copy of each dependency in my tree, and knowing that _all_ of my interdependent requirements resolve to it.

- `uv lock --upgrade` is written like that because it upgrades the lockfile, not the user's own requirements. By contrast, `pnpm update` appears to update the user's own requirements (in package.json). I can see why this is confusing, but I think it's strictly more precise to place under `uv lock`; otherwise, we'd have users with competing intuitions confused about why `uv upgrade` doesn't do their idea of what an upgrade is. Still, it's certainly something we could surface more cleanly, and there's been clear user demand for a uv subcommand that also upgrades the requirements directly.

[1]: https://news.ycombinator.com/item?id=48230048

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

#16

Post by daemonologist »

scorpioxy wrote: post #8

Interesting point of view and I think feedback is good. Although I agree with the overall sentiment of the article, I disagree with the intensity of the criticism. Having a command runner within your project will mask a lot of the issues the author mentioned. And although, in my experience, having a command runner for mid-sized projects and up is useful for many things, masking the UX issues means there's a problem.…

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.

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

#17

Post by mrtranscendence »

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

That doesn't work for library projects, though.

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

#18

Post by jim33442 »

galangalalgol wrote: post #11
jim33442 wrote: post #9

Earlier quoted context omitted.

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

Isn't there a lock file for that? I'm mostly a rust dev, but I thought I saw a lock file in a uv project I was vibe coding

The lockfile does more than just pin the versions of your immediate deps, so one might reset it for some other reason. Or you might want to update individual packages without caring about the specific commands for that, so you edit the package file, delete lockfile, reinstall.

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

#19

Post by kibwen »

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 use or adherence to semver isn't the problem here. As you say, if a package follows semver, it's easy enough for the package managers to automatically update to newer compatible versions. The problem is when you want to have two different incompatible versions of the same package `foo` in the same program, because then you have to figure out what `import foo` means. You might say "just don't do that", but that package could be an indirect dependency of several of your direct dependencies. Some languages handle this natively, e.g. in Rust it just works if you have multiple versions of the same library in different parts of your dependency tree (and you'll get a compilation error if you try to pass a type from one version into a function of an incompatible version). But Python does not handle this use case very well.

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

#20

Post by jim33442 »

mrtranscendence wrote: post #17
jim33442 wrote: post #9

Earlier quoted context omitted.

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

That doesn't work for library projects, though.

Yeah that's true. I can't imagine someone making a lib would just install deps without specifying version ranges, but maybe they do.
Post reply on HN