- cross-posted to:
- python@programming.dev
- cross-posted to:
- python@programming.dev
After seeing yet another dozen packages lose keywords on Gentoo because of a single key dependency switching to uv-build, I would like to plea on behalf of Gentoo users: please don’t use uv-build as a build backend.
Just to be clear, this is not about uv itself or any other Astral tools; these are good tools with a nice and responsive upstream. The uv-build backend is one thing we have to disagree on. I’m not saying it’s bad; I’m saying that its benefits don’t outweigh the drawbacks.
You must log in or # to comment.
I’m going to be completely real with you, I’m really not sure how many developers have the Gentoo user base that high on their list of priorities.
It’s a huge dependency (as of 0.13.0, its wheels are between 1.2 MiB and 1.5 MiB
What world are they living in that 1.5MiB is huge?
SPARC
Right.
Its cool you want to keep your old system going, but thats a cost you have to pay. You can’t expect the rest of the world to make their lives harder to support your niche.
What world are they living in that 1.5MiB is huge?
That depends. Am I buying the SSD last year, or today?
The RAMpocalypse is going to make “this doesn’t run on a low-powered low-capacity device” a much more relevant issue.
You can’t expect the rest of the world to make their lives harder to support your niche.
I bet you wouldn’t say that shit to your boss, or a billionaire
I absolutely would say that to a billionaire, because they aren’t paying me.
My boss, have said it a number of times. I’ve almost verbatim told them that their use case doesn’t line up with our broader user bases’ use case, and that I wasn’t going to support it. Part of a healthy working relationship is being able to push back.
Ignoring my specific case though, what is your point? That people with power shouldn’t ever face push back? Surely that’s not your point?
Believe it or not, my point was exactly what I said it was; without subtext. Fwiw, the reason I made it is that not supporting older systems is something peoole tend to do to appease the commercial interests of their employers, and the broader and higher classes of employers. Imo, it sounds more like you told your boss that their strategy didn’t align with their own interests than what you said to the quote in question.
There are other good reasons to not support older systems, beyond commercial interests.
Every additional system that is supported comes with a cost of time and effort. When the system is rare (SPARC), continuing to support it doesnt make sense, especially when that time and effort can be put towards maintaining other more common systems.
Also, supporting older systems can hold back new technology. Most Linux distros are built with an ancient minimum x86 version, which means that many of the modern CPUs aren’t being optimised for. Its good for compatibility, but it is holding back new systems. Every Ubuntu/fedora/etc release their respective steering committees will usually have a discussion about dropping older CPU support. Gentoo at least has a solution for that, because everything is recompiled for the specific system.
IMO, if their system is so resource constrained that 1.5mb is too much to bear, they’re well into the “holding everyone else back” territory, 128GB SSDs are 40AUD, which is two big Mac meals. And if they are on SPARC, thats well into the rarity territory, the last SPARC CPU was released in 2017, and they were never common for consumer PCs.
There is a difference between “planned obsolecence” and actual obsolecence, and this case feels like the later.
The additional work doesn’t go away when you add support for higher end systems that most can’t afford to use, let alone want to.
This premise, that progress requires abandon, is taken for granted because of commercial interests.
If people were as interesting in maintaining their projects as they were in riding the new wave, there’d really be no issue.
I don’t use Gentoo or uv-build, but I don’t get the problem.
Gentoo builds packages from source for each user. Okay.
But I assume that it can’t be building the entire toolchain from scratch for each package. It can’t be rebuilding, say, GNU autotools for each package that uses it during its build. It’s presumably either packaging the toolchain dependencies and not updating them between packages or caching the build.
Why can’t Gentoo just do whatever it does there for this uv-build thing?
EDIT: Here’s a Hacker News thread on this same article, which I turned up in trying to get some context:
https://news.ycombinator.com/item?id=50076048
I discovered partway through that I don’t care as much about Python or Gentoo build expectations as some of the people involved, enough to fully understand it, but it sounds like, from a quick skim, that some people feel that there are unspecified expectations from the Python build environment. Some people feel that an unspecified dependency version means that one must use the latest verson as of time of build, and since Gentoo typically builds packages for a given user at different times, this entails using different versions of the build tool. Others do not feel that way.
Some snippets:
UV maintainer asking why Gentoo doesn’t just pick a version and freeze there and then some responses
(I am one of uv’s maintainers.)
…I don’t understand why Gentoo needs to rebuild every single release of uv-build. It doesn’t change as much as uv itself, and it’s intentionally compatible across uv versions. Why not set a policy of only updating once weekly, or even less frequently, with exceptions for important breaking changes or bug fixes?
Because if you don’t pin a version of uv-build in your project, that means “use the latest version available”. Gentoo can’t second guess you–even if it were able to verify somehow that the new version of uv-build that just got released will end up producing an identical wheel for your project as the previous version, without actually using the new version of uv-build.
Other distros don’t necessarily have quite the same problem because, if they include packages of Python projects, they don’t normally track the build backend as a dependency. So if uv-build pushes an update, the distro would push an updated package for uv-build, but they wouldn’t look at every Python project they package to see if it used uv-build as a build backend and rebuild it if it did. It’s the “rebuild from source every time” aspect of Gentoo that forces that connection.
i guess gentoo is rolling-release, vs something like debian where every package is frozen in time (+ backports), and debian does seem to largely solve the coordination problem by making everything on the system use a fixed version of some package; with rare situations allowing >1 version of the package at a time.
my take on linux distros being annoyed by their own policies is that perhaps they should change the policy. in this case, perhaps they should pretend uv-build updates once a month or something.
Somewhat of a side discussion, but these aren’t the only issues you can have when using uv-build.
While it’s stable now, it expects certain directory layouts and can only be used on pure Python projects. If you need anything else, you are better off using hatchling anyway, which used to be the default even for uv.
This is also why some of your old uv-based projects might build fine and the same code won’t build in a modern uv project; they switched the default.
Here’s a thing directly from the authors:
While the backend supports a number of options for configuring your project structure, when build scripts or a more flexible project layout are required, consider using the hatchling build backend instead.
