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

101–110 of 161 posts

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

#101

Post by syntacticsalt »

Pixi uses uv as a backend, and I've enjoyed the UI because it's easy to add task aliases for things like nicely-formatted lists of outdated packages. (I have no affiliation with the project.)

Pixi-diff-to-markdown in particular has made scanning automated CI package updates easier. So for something like viewing outdated packages that would be updated, I'd do something like create a task alias for a project:

pixi task add outdated "pixi update --dry-run --json | pixi exec pixi-diff-to-markdown"

And then run the task in the project via:

pixi run outdated

The output is a readable Markdown table of packages that would be updated, old version, and the new version that would be installed using the pixi update command. Your mileage and tastes, of course, may vary.

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

#102

Post by arcatek »

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.

Curious how you did this; I looked into that couple of months ago but even with custom hooks the Python injection points seemed to limited due to the internal resolution cache.

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

#105

Post by kjmr »

zanie wrote: post #75

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

“Removing upper version bounds is important when publishing libraries.”

That makes total sense! The article however was written as someone creating websites, not libraries. And when I consume dependencies in my web project, I do want those upper bounds to prevent breaking changes (assuming the dependencies respect SemVer of course).

Thanks for pointing out that config, I’ve updated the article.

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

#107

Post by coldtea »

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…

>If an upper bound were to be supplied you would end up with trees that can no longer resolve in practice.

And then we'd have to run uv again with an argument to not have upper bounds. Oh, the humanity!

As opposed, to it nuking our dependencies with incompatible packages.

Doesn't sound like the unsafe option should be the default.

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

#108

Post by coldtea »

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

His lament isn't that uv lacks upper bounds.

His point is that the cli experience of uv is badly designed. And having upper bounds an opt-in is another point he makes in that.

Also, the overuse of the term "clickbait" for anything we don't agree with is ...clickbait.

> So not really sure what he's complaining about

It says it on the bloody title of his post: UV's "package management UX is a mess".

He's complaining that upper bounds by default would the good choice, and that UV potentially nuking your deps by default is bad. And that the whole UX around uv updates is bad in general, for which he gives several examples.

We can argue if he's right or wrong about each of those, but it's pretty clear what he complains about.

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

#109

Post by a3w »

fermigier wrote: post #96

I was really surprise by the recommendation to use "uv tree --outdated --depth 1" to list outdated deps. I personally use "uv pip list --outdated" since it has been introduced. I agree that this is such an important command that it deserves its own top-level subcommand, though.

"uv tree -od1" probably works. But yes, critique of pacman and other managers was that it needed to offer human sounding commands for frequent commands, like apt does.

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

#110

Post by yorwba »

mroche wrote: post #86
skeledrew wrote: post #52

Earlier quoted context omitted.

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

This sounds... not possible for the core problem of how Python handles dependency resolution during the life of an application? How are you setting things up so that the following scenario is valid? program ├── dependency_a │ └── dependency_c (1.0.0) └── dependency_b └── dependency_c (2.0.0) Otherwise, you've created a magic layer hack to enable multi-version dependency chains in a mono-version dependency chain langu…

Python's import system is extensible: https://docs.python.org/3/reference/import.html#import-hooks It might be possible to create a custom finder that will return 1.0.0 when running "import dependency_c" in dependency_a but 2.0.0 for the same import statement in dependency_b. You'll need to work around the module cache in sys.modules, though. And good luck trying this on a package that also hooks the import system...
Post reply on HN