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

151–160 of 161 posts

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

#151

Post by gandreani »

black3r wrote: post #142

We have 257 python dependencies in our production app (over half of them are direct dependencies). We don't have any upper bounds in our pyproject.toml and we just run `uv lock --upgrade` every 2 weeks through GH actions. 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 ma…

Writing tests is also something AI agents excel at. At least they excel at converting plain english instructions into exact tests.

I haven't hand written tests in a while and it was something that I always bemoaned. Not anymore!

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

#152

Post by junkblocker »

Here's something I ran into recently. An `env` script started showing up in my path messing with my plain UNIX `env` command usage. Turns out uv's installer creates this when you run

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
What kind of programmers are writing this stuff overriding my default unix commands with this?

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

#153

Post by foobarbecue »

zanie wrote: post #78
foobarbecue wrote: post #37

Earlier quoted context omitted.

Rust isn't the main reason it's fast. The main reason is willingness to break backwards compatibility. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

I don't think it's true at all that "dropping features" makes uv fast. As an author of uv, I think that particular section of the article is way off base.

Copy that, thanks for the info. I was taking the article at face value.

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

#154

Post by jeremyjh »

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…

The Haskell community wrestled with this for many years - may still I haven't really kept up. Last I was involved the most successful thing going on was Stackage where they encouraged no defensive upper bounds and ran continous builds on a large chunk of the most active parts of the ecosystem with every release to find actual compatibility issues, with automation to handle notifications back to owners and clear timelines if you wanted to stay in the next "LTS" release.

Things now seem to be stable enough that you just need the Cabal solver - but I suspect the broad nightly builds and visible failures/blockages probably help keep the ecosystem solvable.

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

#155

Post by brewmarche »

brewmarche wrote: post #147
0x3444ac53 wrote: post #143

Earlier quoted context omitted.

Hi, out of curiosity is there a way to persistently set the `--native-tls` flag? UV always fails without it because of Zscalar configurations at my day job. Also, is there any plan to add support for specifying that a compatible python version for a specific architecture? One of the packages I maintain at work has to use 32 bit python, and I always have to pass the `--python /path/to/32bit`

Yes you can set it via an environment variable (UV_NATIVE_TLS=true) or in your uv.toml (native-tls = true). However, check the docs, I think they are renaming it to sytem-certs.

Looks like I forgot to answer the other half :) Yes you can pin a specific Python like `uv python pin cpython-3.14.0-macos-aarch64-none`, it will create a `.python-version` file which will be respected when you’re in the directory.

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

#156

Post by FDETalkDotCom »

imp0cat wrote: post #83
FDETalkDotCom wrote: post #62

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

If it feels wrong to use uv to manage dependencies, you don't need to go that far. Start with replacing `pip install` with `uv pip install` for a huge free speed boost.

Whoa, yeah, I think I will be switching to this which is much faster, (thanks!):

  uv pip sync requirements.txt
instead of

  python3 -m pip install -r requirements.txt

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

#157

Post by skeledrew »

arcatek wrote: post #102
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.

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.

Its just objects accessed via RPyC[0] and exposed with import hooks. Thinking of a Show HN but there repo isn't really publish-ready.

[0] https://rpyc.readthedocs.io/en/latest/

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

#158

Post by skeledrew »

yorwba wrote: post #110
mroche wrote: post #86

Earlier quoted context omitted.

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

Yep that's pretty much how I do it, along with RPyC[0] for connection.

[0] https://rpyc.readthedocs.io/en/latest/

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

#159

Post by skeledrew »

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…

I'll try to get around to a Show HN some time for it, but it's essentially as sibling reply states.

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

#160

Post by jim33442 »

galangalalgol wrote: post #57
jim33442 wrote: post #18

Earlier quoted context omitted.

The lockfile does more than just pin the versions of your immediate deps, so one might reset it for some other reason. Or you might want to update individual packages without caring about the specific commands for that, so you edit the package file, delete lockfile, reinstall.

But if I use uv sync and the package I want I don't ever need to toss the whole file right. In rust I'd never sign off on a mr that just randomly updated lots of deps with no reason tied to the issue they were resolving

Not sure. Those lockfiles don't seem really human-readable. I wouldn't approve a change that randomly changes the lockfile without explanation, but I would also want the project file to set the requirements rather than relying on the lockfile, cause that's not the lockfile's job.
Post reply on HN