My flow is exact pins always, Renovate/Dependabot to inform me of new versions, or uv tree --outdated.
Uv is fantastic, but its package management UX is a mess
91–100 of 161 posts
Re: Uv is fantastic, but its package management UX is a mess
#92> 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
#93Re: Uv is fantastic, but its package management UX is a mess
#94Interesting 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.…
Re: Uv is fantastic, but its package management UX is a mess
#95Re: Uv is fantastic, but its package management UX is a mess
#96I 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
#97Earlier 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.
Re: Uv is fantastic, but its package management UX is a mess
#98Re: Uv is fantastic, but its package management UX is a mess
#99(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…
Re: Uv is fantastic, but its package management UX is a mess
#100(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…
> In the eyes of uv, pydantic version 2, 3, and 100 are all perfectly acceptable.
Without semantic versioning, they are.