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.

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.

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.

Have successfully installed py315 pyenv install 3.15.0

Which packages currently support py315

pyenv please do what you do so can start testing py315

no. No it wouldn't. It would break 99.9999% of python interpreter version checks cuz we are all following the exact same patterns.

... the next day you'd be here saying that was a really bad idea.

Luckily people smarter than us already decided that was not worth pursuing. And we are better off for those folks with foresight instead of 100% clarity in hindsight.

Well they better can distinguish between 3.141 and 3.oom_killer invoked.

Any code that correctly distinguishes between 3.9 and 3.10 would also handle 3.14 and 3.141

Finally a fast and elegant way to flatten lists using PEP 798: [*x for x in L]

Luckily people smarter than us realized code checking for versions couldn't distinguish from 3.14 and 3.14blahblahblah

That idea sucks please forget you ever supported it and i'll do the same. The point is now mote anyway.

Shame, I really like the idea of Python π (or, as I call it, πthon)

The lead up to py315 is better than sex. Out with the py310 (2026-10-01) in with the py315 (2026-10-09)!

Waiting one more whole day is torture.

I get to be this excited for lazy imports

Can't tell if made a convincing argument or sneezed without covering my nose.

The entire point of the argument was to convince others to deliberately not engage it. It being ruff.

A clearer comment might be, "yeah i love flake8, black, and isort. They are great or at least sufficient!"

Yeah, I saw the other comment and decided to deliberately not engage it.

ruff is Rust. I stay away from introducing Rust into Python tech stack. Since if something goes wrong, the burden of maintaining it falls upon user base all of which are not Rust experts. It's a heavy burden.

Would recommend removing it.

What's the ruff pitch? memory safety in a linter is about as important/useful as tits on a bull.

Das ist sehr gut!

I've already been using typos, and if I understand correctly have ruff rulea that do what interrogate does

Thanks, but I also give a solution link, so people can already cheat if they really want too.

I was trying not to spoil that a |= b and a = a | b have different semantics though, as that pretty much winds up giving away the answer IMO

Been seeing most packages atm supporting py310 - py314. Other abandoned packages just have py3+ which is good enough.

The issue is when you go full async native and drop sync codebases. Then no choice but to step up and help maintain other AWOL author/maintainers projects.

Glad to be helpful. Did you try out interrogate and typos?

Thanks a lot, I hope it can bring much value for you.

Yeah, the visualisation is great, that is for sure

The point of the visualization at the Solution link is precisely to help people get the right model of how labels and the data model in general works in Python. See the Explanation link for more details.

Great, I hope it can bring much value for your teaching.