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

141–150 of 161 posts

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

#141

Post by strangelove026 »

woodruffw wrote: post #40
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…

I think you want `uv tool install` and `uv tool upgrade` for that. But also: please file an issue, because it sounds like the kind of papercut we could address somewhat easily!

Could it be a code artifact thing? I’ll see about opening an issue soon enough

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

#142

Post by black3r »

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

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

#143

Post by 0x3444ac53 »

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…

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`

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

#145

Post by WorldMaker »

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…

Arguably the other reason for a lack of a default upper bound stems from PyPI has never required semver for hosted packages, there are plenty of packages on PyPI still using calver or marver or other more bespoke version schemes. (Whereas npm has always made semver an assumption/"requirement" for hosted packages.)

As someone part of the problem with a couple ancient packages in PyPI that are calver (though arguably I'd be surprised if many depended on them), I wonder if it is too late for more of the Python ecosystem to shift more directly to semver by default/everywhere as some of the other ecosystems now are.

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

#146

Post by CivBase »

I heard a lot of great things about uv before finally having a chance to dive into it over the last month and... honestly I'm not sold. It's fast, but the UX feels like it's mostly just a wrapper around older tools.

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.

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

#147

Post by brewmarche »

0x3444ac53 wrote: post #143
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…

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.

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

#148

Post by alasdairnicol »

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…

Forgive me for asking a slightly inhaled question - Is there a way to get uv to respect `exclude-newer` in `pyproject.toml`?

When I run `uv run` it removes `exclude-newer` from pyproject.toml.

I could run `uv run —-frozen` or `uv run --exclude-newer` all the time, but that doesn’t seem quite right. Is there an idiomatic flow that I’m missing out on?

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

#149

Post by ilayn »

physicsguy wrote: post #136
ilayn wrote: post #135

Earlier quoted context omitted.

Scipy maintainer here, the main issue with the wheels was the Fortran77 that was SciPy throwing wrenches into the mix. With C/C++ self compilation should be quite straightforward. We (all Scientific Python packages) really worked hard on that. From version 1.19 of SciPy there will be no need for fortran compilers (because we translated everything to C https://github.com/scipy/scipy/issues/18566 ) and then all becomes…

Thanks for all your hard work! I already consider SciPy and NumPy to be best practice in this area but as I'm sure you know, it's the long tail of stuff built on top of these and other core packages that are really the issue!!

Ah, my bad. what I failed to emphasize is that many of the downstream issues are coming from the upstream restrictions so this is one of the major blocks that was causing some mayhem down the line. So indirectly we might have caused some heartburn for you, apologies in advance.
Post reply on HN