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

71–80 of 161 posts

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

#71

Post by JimDabell »

thayne wrote: post #43
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…

> `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’s what the --dry-run argument is for.

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

#72

Post by a_t48 »

FDETalkDotCom wrote: post #62

The author seems to use uv with Python (somewhat) fundamentally differently that I do. I don't expect uv to do anything fancy. I don't run module management (installation, upgrades) through uv commands. I don't much care what uv's syntax is. I let each tool do one thing. - Tool 1: UV makes a venv for each project, with whatever Py version is suitable for that project, so that each project's dependencies do not collid…

If you're the only person using the project...not really doing it wrong, your preference. If you have to share it, you can encode the supported python version(s), exclude-newer, etc, in pyproject.toml. Using a lockfile also helps against supply chain attacks - restricting the danger window to only when running upgrade rather than on any install. It also stops accidental breakages from occurring. If you lock once, you know that anyone else can install using the same lockfile, no matter what other versions have gone out in the wild. (Pyproject also can encode things like package groups, which IIRC doesn't work so well with requirements.txt)

I personally don't really use `uv add` and `uv lock --upgrade`, in the past I'd just hand edit the pyproject to pull forward my dependencies and let `uv lock` figure out the rest.

A good third of my last job was spent chasing after projects that weren't using pyproject. It typically turned multiple steps of "install python, upgrade pip, install this one special library, install requirements" inside of a Dockerfile or bash script into one `uv` command. And was more reliable afterwards, to boot!

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

#73

Post by zanie »

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…

fwiw `uv upgrade` is on the roadmap — we just haven't done it yet because it's hard to build a great experience for it (there are far more nuances than people expect) and we're a small team with a lot of priorities.

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

#74

Post by zanie »

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'm a bit confused, `uv run --with $package main --help` should do what you say with very little overhead. We won't reinstall it every time, `--with` environments are stored in the cache and retained. Even if the environment is cached, the dependency is cached and installing from the cache is very fast (Please feel free to open a reproduction with details and we can look into it.

(I work on uv)

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

#75

Post by zanie »

(I work on uv)

As a note, you can set the default bounds for `uv add` in persistent configuration — no need to provide it every time. See https://docs.astral.sh/uv/reference/settings/#add-bounds

We prefer not to add upper bounds by default because it causes a lot of unnecessary conflicts in the ecosystem. I previously collected some resources on this back when I used Poetry :) see https://github.com/zanieb/poetry-relax#references

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

#76

Post by deathanatos »

__mharrison__ wrote: post #60
kibwen wrote: post #19

Earlier quoted context omitted.

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?

The monolith I work on has this dependency chain:

  monolith -> openai
  monolith -> langchain-openai -> openai
openai, thus, is both a direct and indirect dependency. langchain-openai recently had a vulnerability, and the patch fix is only after a major upgrade to openai. Thus, to upgrade langchain-openai here, I also need to upgrade monolith's use of openai. (From v1 to v2.)

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

#77

Post by epage »

kjmr wrote: post #33
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.

Not having used uv but being on the Cargo team for Rust, I wish `cargo update` was `cargo lock update` because it is making our life more difficult to add a version requirement update command/mode inside of Cargo. The effort has been stalled for years.

- Our compatibility guarantees mean we can't fundamentally change `cargo update`

- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two

- We have to be very careful adding the mode to the existing command

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

#78

Post by zanie »

foobarbecue wrote: post #37
jim33442 wrote: post #23

Earlier quoted context omitted.

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

I don't think it's true at all that "dropping features" makes uv fast. As an author of uv, I think that particular section of the article is way off base.

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

#79

Post by deathanatos »

saghm wrote: post #31
wrs wrote: 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 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 anythi…

> not that you assume that the types of changes that can happen in a type of bump will happen

… an assumption that something happened is not a definitive statement that it did happen, only that we're assuming it did, because it could happen, or perhaps here, that because the major was bumped, that it is legal, according to the contract given, for it to have possibly happened in a way that we depended on. They're not saying that it will/must; "assume a major version is incompatible" is not at odds with what you've written.

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

#80

Post by deathanatos »

scubbo wrote: post #56
pie_flavor wrote: post #54

Earlier quoted context omitted.

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.

> Knowledge only cements itself in the brain when it's regularly referenced.

While true, this is a molehill, not a mountain, of a bar, like "coding once in a while". I'm doing mostly SRE work, and this syntax has no trouble sticking in my head, and I encounter it pretty regularly? (And heck, most of my work these days is in Python, so there I get the >=,If you're actively developing a codebase, this definitely isn't going to be arcane trivia.

Post reply on HN