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

21–30 of 161 posts

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

#21

Post by strangelove026 »

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 version 3. Update if it’s not on the latest version

All three were surprisingly tricky to accomplish.

By default uv run will reinstall it every time. Which is 6 seconds of venv and installs

uvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades.

I ended up having the script run a paginated GET on codeartifact and update if there’s a newer non-dev version (and then re-execute).

That seems to work. And 200ms delay is better than 6 seconds. But it wasn’t quite the experience I wanted.

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

#22

Post by fletchowns »

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…

> uvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades.

Couldn't the user just run `uv tool upgrade `?

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

#23

Post by jim33442 »

daemonologist wrote: post #16
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.

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.

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

#24

Post by williamjackson »

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…

Coming to uv from pip, I fall back to

    uv pip list --outdated
when I need that information.

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

#25

Post by huflungdung »

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…

[dead]

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

#26

Post by saghm »

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…

As much as uv has improved the situation, I have to imagine that there's plenty of stuff like this that fundamentally is impossible to address via tooling. It's incredible how much the situation seems to have improved compared to before it was around, but it seems like things might never be totally good without the ecosystem as a whole making some breaking changes, and I'm guessing after the whole 2->3 situation there's not much appetite for something like that any time soon.

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

#27

Post by strangelove026 »

fletchowns wrote: post #22
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…

> uvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades. Couldn't the user just run `uv tool upgrade `?

That command takes 6 seconds I believe as well if I remember correctly. And likely there isn’t a ton of churn on the script. So having it make a new venv each time is kind of annoying. I was trying to aim for a good balance of fast and developer experience.

Basically if there’s an upgrade everyone needs to be using the most recent version, I didn’t want to rely on a pr dance to pin versions, and I also didn’t want to rely on everyone running a command when there’s a change

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

#29

Post by rtpg »

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

The distinction here is on application vs library, IMO. I basically agree that applications, as a default, `==`'ing everything makes sense.

For libraries, having loose bounds might mean that users upgrade and hit issues due to a lack of an upper bound. But given how lightly maintained most projects are, the risk of upper bounds simply getting in the way are higher IMO.

(Put an upper bound if you know of an issue, of course!)

It's a bit tricky though. Django deps in particular tend to want to explicitly check support for newer versions, but the more I think about it the more I ask myself if this is the right strategy

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

#30

Post by jimbokun »

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

Or to introduce a major exploit.
Post reply on HN