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

61–70 of 161 posts

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

#61

Post by __mharrison__ »

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.

Isn't designing for machines "the way" these days?

(Ducks...)

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

#62

Post by FDETalkDotCom »

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 collide with one another.

- Tool 2: Pip installs all the requirements for a given project, within the venv for that project. From a requirements.txt file. Which, as far as I am aware, pip commands and requirements fit more of what they author is looking for.

I don't think it's necessary to subject oneself to the things the author (articulately) complains about, e.g.: uv's command syntax for listing packages; uv's emitting unbounded requirements syntax; uv's command to upgrade modules

Then again, it's quite possible the author is managing modules in projects with more complex needs than I am.

Long-winded example:

  # Make an env for the project with appropriate Python and use it
  uv venv ~/.venvs/myprojpy312 --python 3.12
  source ~/.venvs/myprojpy312/bin/activate
  
  # Make sure pip exists and is up to date
  python -m ensurepip --upgrade
  python -m pip install --upgrade pip

  # Fill in requirements.txt in readable/meaningful syntax per needs
  $ cat requirements.txt
  requests>=2.31.0,
And in the age of the supply chain attacks, requiring a certain staleness could be useful, too (providing time to catch recent and revoke reasonably major and recently discovered issues, though at the cost of also blocking recent fixes):

  $ cat ~/.config/uv/uv.toml
  exclude-newer = "7 days"
  # per https://news.ycombinator.com/item?id=47884491
Am I doing it wrong? Should I be thinking about `uv lock --upgrade`, `uv add`, and `uv tree --outdated` like the author? I'd rather just avoid all that, and have been able to so far.

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

#63

Post by aleyan »

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…

Agree with you on outdated and upper bounds. However, if users are complaining about the interface being difficult, there is probably something there.

Yes, it makes sense that `uv lock` commands only work the lock file, but users have real needs to upgrade direct and transitive dependencies. For transitive dependencies `uv lock --upgrade-package` works, even if a bit wordy. For direct dependencies, `uv lock --upgrade-package` also works, but doesn't touch `pyproject.toml`, which is much more developer visible. As `uv.lock` package versions get ahead of `pyproject.toml`, `pyproject.toml` becomes a less dependable guide to the surface area of dependencies. A friendly `uv upgrade` command would be nice.

The biggest uv ux footgun I have seen by far is `uv pip`. I have seen a lot of projects use uv correctly with pyproject.toml/uv.lock for development, but then use `uv pip install -r pyproject.toml`, which bypasses uv.lock, in their deployment Dockerfiles and ci tooling. Yes, coding agents are to blame for recommending bad `uv pip` patterns because they have so much `pip` in their training sets, but uv should provide some affordances to protect the user.

Sorry for the rant, uv is a great tool, that I think[0] should be used more! Thank you for your contributions to the ecosystem.

[0] https://aleyan.com/blog/2026-why-arent-we-uv-yet

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

#64

Post by thayne »

skeledrew wrote: post #58
thayne wrote: post #43

Earlier quoted context omitted.

> `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 confirmation prompt would then lead to surprises in CI pipelines.

Well, I think the ideal would be to default to prompting, but have a "--yes" or "--non-interactive" option to turn it off in CI and similar, but that might be problematic for backwards compatibility now, but an "--interactive" or "--prompt" flag now would be better than nothing. Especially, if you can configure that in ~/.config/uv/uv.toml

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

#65

Post by gbear605 »

__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?

This is Java, but recently I had a case where one library depended on a version of an Apache Commons library, and another library depended on a different version of the same Apache Commons library, and neither version worked with both libraries. In my case, I was able to upgrade one of them to a newer version so that I could use just one Apache Commons version, but I got lucky there.

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

#66

Post by meander_water »

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

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

#68

Post by ilvez »

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…

isn't ~= supported by uv or the discussion is about uv not adding it when package is added by command line rather than editing pyproject file? ~= is standard practice for me, as I always rather edit the file than memorize the commands.

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

#69

Post by kortex »

kjmr wrote: post #44
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…

The lack of an upper bound in pyproject.toml isn’t the real problem. The real problem is that `uv lock —-upgrade` does a wholesale upgrade of everything without an upper bound. If there was a way to upgrade packages without updating the major version, this command would be a lot safer to run.

I'm not in front of my terminal, but I'm almost certain there is a way to do this. And if not, it would not be hard to add.

I can't really take the article fully seriously when they are like "uv cant do this. Well actually it can but you gotta use an extra flag." It reads rather PEBKAC.

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

#70

Post by kortex »

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…

You might wanna check out https://copier.readthedocs.io/en/stable/

Dunno if it's your exact use case but it's been amazing for keeping a polyrepo microservice ecosystem in sync.

Post reply on HN