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

131–140 of 161 posts

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

#131

Post by DangitBobby »

pie_flavor wrote: post #54
jimbokun wrote: post #28

> Poetry does the same by default, using a format like >=1.23.4, What??? I understood the first format instantly, but had no idea what the second meant until the author explained it.

And then you look it up once, and now you know what it means forever. By contrast, the former expression is much wider with more going on, and furthermore you can't skim past it being sure nothing funny is going on because it may or may not be a range compatible with the latter form.

I've looked up the ^ and ~ syntax differences probably half a dozen times. They are arbitrary and un-intuitive.

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

#132

Post by DangitBobby »

egorfine wrote: post #113

I hate the state of python packages ecosystem. The other day I wanted to install isd on Ubuntu. 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.

They don't want you installing things in your system python environment (though AFAIK you can bypass this still) because it could get clobbered by an update at some point, and the tools you rely on would suddenly disappear, or worse, the things that depend on your python environment being a certain way could become broken in confusing and hard to debug ways. uv is typically installed as a separate program that manages python than as a python dependency.

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

#133

Post by egorfine »

DangitBobby wrote: post #132
egorfine wrote: post #113

I hate the state of python packages ecosystem. The other day I wanted to install isd on Ubuntu. 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.

They don't want you installing things in your system python environment (though AFAIK you can bypass this still) because it could get clobbered by an update at some point, and the tools you rely on would suddenly disappear, or worse, the things that depend on your python environment being a certain way could become broken in confusing and hard to debug ways. uv is typically installed as a separate program that manage…

Yeah I know. And I know that deps management is very hard, and much more so in an environment not used to any package management at all (python).

Still its a mess

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

#134

Post by gegtik »

euiq wrote: post #121
kjmr wrote: post #105

Earlier quoted context omitted.

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

Yes, and he is discussing how `uv lock` updates the contents of that file

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

#135

Post by ilayn »

physicsguy wrote: post #125
bartread wrote: post #124

Earlier quoted context omitted.

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.

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 much easier in all platforms due to the large availability of C compilers in all platforms. Together with the Stable API developments in CPython the wheel clash issues "hopefully" will decrease gradually.

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

#136

Post by physicsguy »

ilayn wrote: post #135
physicsguy wrote: post #125

Earlier quoted context omitted.

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.

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

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

#137

Post by lucideer »

> "a mess"

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.

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

#140

Post by wrs »

saghm wrote: post #85
deathanatos wrote: post #79

Earlier quoted context omitted.

> not that you assume that the types of changes that can happen in a type of bump will happen … an assumption that something happened is not a definitive statement that it did happen, only that we're assuming it did, because it could happen, or perhaps here, that because the major was bumped, that it is legal, according to the contract given, for it to have possibly happened in a way that we depended on. They're not…

You and I have a very different version of what the equals sign means. "This is a reasonable action to take in this scenario" is not what I understand as equivalence.

Perhaps I should have used an implication sign -> instead of an equals.

Semver says “major version MUST be incremented if any backward incompatible changes are introduced to the public API.” You’re correct that it doesn’t say “major version MUST NOT be incremented if there are no backward incompatible changes”, so technically that is possible — but it would be a very odd thing to do.

Post reply on HN