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-relax#references

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 ecosystems in Python even went as far as publishing overrides for old packages that got published with assumed upper bounds that ended up wrong.

Don't forget that you cannot know today if your package is going to be compatible or incompatible with a not yet released package.

We have good test coverage so if anything breaks the tests fail + we have AI assisted review process for this -> when GH action creates the upgrade PR, an AI workflow uses a python script to list major and minor version updates, finds and links changelogs, summarizes them, and makes the risk factor analysis for each package based on how we use it in our codebase.

It's mostly painless and we don't have to deal with upgrading packages one-by-one, checking which packages are outdated, or having outdated packages. Very rarely something breaks in a way it can't be fixed in our code and we need to wait on a fix from the dependency author (maybe once a year?). And in the past 3 months only one such upgrade required some changes to our code, there were 18 major version bumps in that period.

I wish we could do this on the frontend as well (I'm a full stack dev), but we don't have enough tests on frontend for this to work safely. Tests on the backend are easier to write and are more important so I believe every codebase should have them. And if you do, you can just auto-upgrade everything.

It really is far easier than you'd think if you haven't tried.

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 version 3. Update if it’s not on the latest version

All three were surprisingly tricky to accomplish.

By default uv run will reinstall it every time. Which is 6 seconds of venv and installs

uvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades.

I ended up having the script run a paginated GET on codeartifact and update if there’s a newer non-dev version (and then re-execute).

That seems to work. And 200ms delay is better than 6 seconds. But it wasn’t quite the experience I wanted.

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.

Want to install PyTorch? which one? CUDA? Oh, OK, then you have to get the wheel directly from them because there are 6 different versions for differnet CUDA versions, and the wheels are too large for PyPi anyway.

Conda offers only a partial resolution to this problem. Spack is great at being ultra configurable and having all the C/C++/Fortran dependencies and compiler toolchains you need, and so allowing ekeing out best performance, but doesn't integrate well with uv etc. so it's difficult to take an experimental ML project written by a researcher and take it through to productionisation with it.

then cites two examples where you have to write a couple extra args..

better title: “QOL changes i wish UV had”

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 vulnerable or broken. By contrast, it appears to be somewhat common in the JavaScript ecosystem to upgrade opportunistically. I don't think this is bad per se, but seems to me like a good demonstration of discontinuous intuitions around what's valuable to surface in a CLI between very large programming communities.

- As Armin notes[1], uv's upper bound behavior is intentional (and is a functional necessity of how Python resolution works at large). This is a tradeoff Python makes versus other languages, but I frankly think it's a good one: I like having one copy of each dependency in my tree, and knowing that _all_ of my interdependent requirements resolve to it.

- `uv lock --upgrade` is written like that because it upgrades the lockfile, not the user's own requirements. By contrast, `pnpm update` appears to update the user's own requirements (in package.json). I can see why this is confusing, but I think it's strictly more precise to place under `uv lock`; otherwise, we'd have users with competing intuitions confused about why `uv upgrade` doesn't do their idea of what an upgrade is. Still, it's certainly something we could surface more cleanly, and there's been clear user demand for a uv subcommand that also upgrades the requirements directly.

[1]: https://news.ycombinator.com/item?id=48230048

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.

curl -LsSf https://astral.sh/uv/install.sh | sh

  1202│    # In this case we need to:¬
  1203│    #¬
  1204│    # * Install to $HOME/.cargo/bin/¬
  1205│    # * Create a shell script at $HOME/.cargo/env that:¬
  1206│    #   * Checks if $HOME/.cargo/bin/ is on PATH¬
  1207│    #   * and if not prepends it to PATH¬
  1208│    # * Ed
 

The article points out one major issue (bounds) & one minor gripe (outdated cmd).

The bounds issue is very serious & more than worthy of an article in itself. It is a single issue though & hardly constitutes "a mess" when considering the entirety of uv.

I don't think uv's UX is perfect - I could point out plenty more minor gripes other than the outdated one mentioned here - but looking at where we're coming from in the Python package management ecosystem it's a goddamn miracle the UX is as good as it is.

To take that as good ui is not a good take.

My flow is exact pins always, Renovate/Dependabot to inform me of new versions, or uv tree --outdated.

Hah! I thought I was the only one. Still very happy with uv though.

Possibly the most frustrating hidden command is `uv pip show {package}` - a) why is it hidden inside the pip subcommand, and b) why is it missing the package's homepage that you get from `pip show {package}`? Given that actually upgrading stuff with `uv` often means going off and finding version numbers yourself, removing the homepage URL from the show output just feels spiteful.

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,<3.0.0
  black==24.4.2
  
  # Install the requirements initially (or again after changing requirements.txt) 
  python -m pip install -r requirements.txt
  
  # List outdated modules
  python -m pip list --outdated
  
  # Upgrade modules, respecting the constraints
  python -m pip install --upgrade -r requirements.txt

  $ cat ~/.config/uv/uv.toml
  exclude-newer = "7 days"
  # per https://news.ycombinator.com/item?id=47884491

What???

I understood the first format instantly, but had no idea what the second meant until the author explained it.

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.

I got on the uv bandwagon relatively recently as most of my work is maintaining older python projects so I've been using it for new builds. Although the speed part is welcome, I couldn't see what the big deal is and mostly keep on using it because it is a popular tool(there are benefits to that in my line of work) and not necessarily because it can do something that couldn't be done before though with a couple of other tools. Whether it is beneficial or detrimental to having all of that functionality within one tool, to me, is a matter of opinion.

The problem to me is that I've seen this cycle many times before. New tool shows up claiming it is far superior to everything else with speed being a major factor and everyone else is doing it wrong. Even though the new tool does a fraction of what the old "bad" tool is doing. With adoption comes increased functionality and demands and the new tool starts morphing into the old tool with the same claimed downsides. The UX issues to me are a symptom of that process.

I still think uv is a fine tool. I've used poetry before and sometimes plain old pip. They're all fine with each tool catering to different use cases, in my opinion. Sometimes you have to add pyenv, sometimes you don't. Sometimes you add direnv, sometimes you don't and so on. And I've cursed at everyone of them at times. However, the fanboyism is very strong with uv which makes me wonder why.

I ran into a frustrating issue today with uv lock. AFAICT there's no way to "unlock" an individual dependency. I either lock everything down or forgo locks entirely. In my case I'm working with two tightly coupled packages - both developed internally to my organization - where package A is dependent on package B and I always want the latest version of package B. But I still want all my other packages to be locked to specific versions.

My thought was to stop using a uv lock file and just go back to pip with all my dependencies pinned with hashes in pyproject.toml. But after some digging I realized there was no way to put dependency hashes in pyproject.toml. So my only solution is to go back to using requirements.txt, at which point I lose out on the primary value-add of uv.

This experience left me feeling like the "new and improved" tools are still half-baked and that I should stick with the old stuff. It's a little slow and clunky sometimes, but I'm familiar with it and once it's setup it just does what I want.

Isd requires uv.

uv? Not installed. Ok, pip install uv. No way, "externally managed" whatever that means.

Ok, install venv. Then install uv. Then install isd. All messages are cryptic, some exceptions were thrown on console for quite vanilla default cases.

thanks for listening

The "unsafe version" is an unreasonable accusation. Do people really believe in semantic versioning—that not bumping the major version means it's safe? It also creates hard-to-resolve compatibility problems, causing more issues than it solves. Not capping dependency versions has basically become the consensus.