> The nice thing about Python packaging is that it’s standardized

But it isn't. Once upon a time, it was: you used distutils. But of course distutils had a lot of problems. Instead of adopting a single standardized solution for those problems, the Python developers punted and let third parties do it. So now we do not have a single standardized solution for building Python packages; we have a bunch of third party solutions, none of which is in the Python standard library.

Yes, all those third party solutions have to be PEP 517 compatible, but that's not standardization on a tool; it's just standardization on an interface between the backend and the frontend. Which is nice, but doesn't solve the problem under discussion here.

> if uv’s build backend doesn’t fit into the hole you want, then you can use any number of other backends that do an admirable job of conforming to the packaging standards.

As the project developer, sure. But as a Linux distro building your python package, Gentoo has to use the build backend you specify. It can't say, well, this particular package is just pure python, so really all we need is a minimal tool to build a pure python none-any wheel. It has to use the backend you specified.

> I don’t understand why Gentoo needs to rebuild every single release of uv-build.

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.

> you can do a normal version bound in your Python build backend metadata

Sure, but how many users of uv-build actually do that? Seems like the answer to that is "not enough to matter".

The problem is packages that use the build backends, and Gentoo is generally not in the business of maintaining that kind of patch.

Admittedly rustification like that is a problem not only for gentoo, I have commercially deployed systems where one of the most annoyings elements of updating is presence of rust in python deps...

Is Gentoo one of those compile-everything-from-source distros?

You pretty much opened with a... I'm sorry for a strong word, but it is what it is... a lie.

No. Python packaging isn't standardized. Tools aren't interchangeable. And they are all bad, uv including. I wish it didn't exist, so that there were fewer problems for people like me, whose job is, essentially, working around the problems created by people who build tools like uv and people who mindlessly adopt them.

To answer to your specific arguments: nobody is going to believe that your proposed solution is going to hold water longer than it takes for milk to go sour. Too many people, too often had burned on Python packaging tools to trust some tool not to break, to be consistent etc. Without even realizing it, you suggested that someone else should use a crutch to work around the problem you created, and you expected them to just go along with the flow and live by the bottom of the barrel lowest possible "standards" that exist in Python packaging world. No wonder they don't want uv-build... why would any sensible person want it?

The chutzpah of claiming portability is astonishing. Everyone knows it is false. Does the OpenAI voting ring help here?

people who are specially interested in packaging and therefore do it for free care about SPARC.

I think mgorny is aware of that; he’s been active on the relevant DPO threads.

(At the end of the day, this is exactly what support tiers are for. CPython, at least to my eyes, has been very transparent about not guaranteeing support for every platform that has a C compiler.)

Gentoo’s decision to support source builds seems eminently reasonable to me, and I don’t think we should reward it with condescension.

The bigger problem, to me, is that it’s not really clear why this is actually a problem for Gentoo. I am glad they perform user-facing source builds, however, because they see things that other distributors don’t.

I doubt this oft-repeated stereotype was every particularly accurate. I'm not aware of any current Gentoo users on the distro specifically for performance reasons. Gentoo users are in it for control over their system and customization.

Or adopt the Nix approach of caching common binary artifacts in a content addressable store and rebuild from source only when needed.

Gentoo made a lot of sense WAY back in a pre-docker world, where you had to run the whole world on the host OS. Being able to compile it all meant you could link it all together with whatever weird combination of optional libraries you wanted. Things like getting sendmail to auth over LDAP, that nobody packaged in the base distro, become possible. And with Gentoo's tooling, you could build a coherent distro to your own unique demands.

Now though? It's way easier to have a herd of unicorn docker containers running that each handle one weird thing in isolation.