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

Post by krupan » Fri, May 22, 2026, 4:52 AM UTC

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…

Post by mau » Fri, May 22, 2026, 5:03 AM UTC

meander_water wrote: post #66

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…

That part of the article almost read like clickbait, because at the end he admits there is an upper bound arg: > uv add pydantic --bounds major So not really sure what he's complaining about

Post by mroche » Fri, May 22, 2026, 5:06 AM UTC

skeledrew wrote: post #52

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…

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

    program
    ├── dependency_a
    │   └── dependency_c (1.0.0)
    └── dependency_b
        └── dependency_c (2.0.0)

Post by ezst » Fri, May 22, 2026, 5:09 AM UTC

epage wrote: post #77

kjmr wrote: post #33

Earlier quoted context omitted.

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

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

deathanatos wrote: post #80

scubbo wrote: post #56

Earlier quoted context omitted.

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