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

121–130 of 161 posts

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

#121

Post by euiq »

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

“Removing upper version bounds is important when publishing libraries.” That makes total sense! The article however was written as someone creating websites, not libraries. And when I consume dependencies in my web project, I do want those upper bounds to prevent breaking changes (assuming the dependencies respect SemVer of course). Thanks for pointing out that config, I’ve updated the article.

`uv.lock` pins exact versions (and hashes) of your dependencies.

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

#123

Post by physicsguy »

`uv` is great but the biggest issue with Python packaging right now continues to be getting it right for scientific and ML packaging.

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.

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

#124

Post by bartread »

physicsguy wrote: post #123

`uv` is great but the biggest issue with Python packaging right now continues to be getting it right for scientific and ML packaging. 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 a…

I had previously got around this by using Anaconda but I don't really like the amount of crap that brings in either, and also it leads to a dev environment that doesn't look anything like production so that sucks too... as a result of which I'm back in the boat you're describing.

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

#125

Post by physicsguy »

bartread wrote: post #124
physicsguy wrote: post #123

`uv` is great but the biggest issue with Python packaging right now continues to be getting it right for scientific and ML packaging. 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 a…

I had previously got around this by using Anaconda but I don't really like the amount of crap that brings in either, and also it leads to a dev environment that doesn't look anything like production so that sucks too... as a result of which I'm back in the boat you're describing.

It's still better than it was 10 years ago (compiling everything from source wasn't uncommon even then!) but it's painful. Comparisons to other interpreted languages aren't really fair though, if JS/TS had as many compiled C libraries, they'd be in exactly the same positions. Go doesn't have the same compiled library thing because of the focus of excluding C dependencies wherever possible.

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

#126

Post by deathlock »

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!

I was thinking the same. Furthermore you have the `-e` flag which lets you install the tool in editable mode, meaning that they are run directly and thus any edit you make will be present when you use the tool.

The only thing that you need to be aware of is that if you add another package or change it's version you need to reinstall the tool. I would suggest first removing it with `uv tool uninstall $NAME` and then reinstall it.

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

#127

Post by thefreeman »

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 can also define required dependencies in a doc block at the top of the file and then just “uv run main” and it will automatically install and cache any dependencies and run. https://docs.astral.sh/uv/guides/scripts/

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

#128

Post by szvsw »

kortex wrote: post #69
kjmr wrote: post #44

Earlier quoted context omitted.

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.

I think `uv lock -P ` to only update a particular package (and transitive deps of course).

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

#129

Post by DangitBobby »

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.

It's not clickbait style.

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

#130

Post by saltmate »

kjmr wrote: post #119
fermigier wrote: post #96

I was really surprise by the recommendation to use "uv tree --outdated --depth 1" to list outdated deps. 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.

Author here. It wasn't a recommendation, it was just the only way I knew how to. "uv pip list --outdated" indeed has much better output, thanks! Though this makes me wonder why are there 2 ways of viewing outdated packages, with wildly different output? The UX is mess...

Cause the "uv pip" entry point is designed to be backwards compatible with regular pip: https://docs.astral.sh/uv/pip/
Post reply on HN