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.

It’s a huge dependency (as of 0.13.0, its wheels are between 1.2 MiB and 1.5 MiB, depending on the platform)

🤣

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.

Source