Live data from Hacker News

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

loopwerk.io

91–100 of 161 posts

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

#92
post #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?

Am I using it differently than everyone else? I don't want an upper bound, I want a specific version. So always ==, never >=, and upgrading a dependency is an explicit action. I don't want to suddenly have a never version.

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

#94

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

[deleted]

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

#95
I like using uv environments better for some stuff instead of Conda environments because of the speed difference. For example, I just tried installing Nvidia's Sana via Conda environment and my system froze during the wheel building phase. So, won't be using Sana as I can't convert the Conda environment script into a uv environment script. Too many errors pop up, even with the help of a coding agent handling the conversion.

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

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

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

#97
post #51

Earlier quoted context omitted.

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?

Am I using it differently than everyone else? I don't want an upper bound, I want a specific version. So always ==, never >=, and upgrading a dependency is an explicit action. I don't want to suddenly have a never version.

That’s how the ‘sync’ flow works (recreating venv, through the lockfile), here discussing specifically updates.

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

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

Wow thanks TIL about the « add-bounds » config! Especially useful for project where pinning to exact dependencies is crucial and easily missed by less experienced devs (end products, not libs)

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

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

Also Python projects often do not even use semantic versioning.

> In the eyes of uv, pydantic version 2, 3, and 100 are all perfectly acceptable.

Without semantic versioning, they are.

Post reply on HN