Live data from Hacker News

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

loopwerk.io

51–60 of 161 posts

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

#51

> 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…

What you’re saying makes sense for library authors. But when I make a website and I depend on a bunch of packages, that’s where I want to be safe when upgrading and I want that upper bound. The —-bound flag really helps, but is one more thing to type and remember.

Maybe when uv knows the project isn’t a library it could default to upper bounds?

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

#52
post #19
post #5

Earlier quoted context omitted.

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 pa…

> Python does not handle this use case very well

I solved this issue a few months ago. Created a tool that essentially allows the use of multiple envs at once, with their own versions of packages at any level.

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

#53

> 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.

Once you know what the ^ means (I always think of “roof”), I do think that one character is easier to read than >=,<

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

#54

> 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.

And then you look it up once, and now you know what it means forever. By contrast, the former expression is much wider with more going on, and furthermore you can't skim past it being sure nothing funny is going on because it may or may not be a range compatible with the latter form.

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

#55

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.…

For me, and I suspect many others, the big deal is that it makes env management simply disappear. Before uv I used conda+poetry for years, and there was always the need to activate the env before doing anything (I used autoenv and ended up with .env files containing "conda activate " in every project), and various other small pains that I actually became accustomed to over the years, but then I'd always be surprised when someone said X didn't work when it was fine for me. The uv came and I felt a great relief that I didn't know I was missing, and suddenly there were also no more surprises.

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

#56

> 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.

And then you look it up once, and now you know what it means forever. By contrast, the former expression is much wider with more going on, and furthermore you can't skim past it being sure nothing funny is going on because it may or may not be a range compatible with the latter form.

> now you know what it means forever

Not, in fact, correct. Knowledge only cements itself in the brain when it's regularly referenced. Because `>=` and `<=` borrow well-established concepts well-established, they are both intuitive to people reading them for the first time, and easier to solidify or to re-infer for someone who's forgotten their meaning.

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

#57

Earlier quoted context omitted.

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.

But if I use uv sync and the package I want I don't ever need to toss the whole file right. In rust I'd never sign off on a mr that just randomly updated lots of deps with no reason tied to the issue they were resolving

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

#58
post #43

(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…

> `pnpm outdated`: this is something that hasn't come up very much, even though it seems reasonable to me. One use for it is to see what would be updated by running "uv sync --update" or "uv lock --update". Although that might be better served by having a confirmation prompt for those commands.

That confirmation prompt would then lead to surprises in CI pipelines.

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

#59

> 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…

[deleted]

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

#60
post #19
post #5

Earlier quoted context omitted.

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 pa…

I'm curious. Do you have real world examples of when you want to do this?
Post reply on HN