distros patch the build process when they package stuff for the distro all the time. why would they "have to" do anything? i'm not super familiar with gentoo but it seems to me like any other 90s era distro where the distro mediates the relationship between the user and the upstream developer for all packages, by applying patches and potentially doing whatever build they want to.

I linked to some of the relevant standards below.

At the end of the day, it’s hard for me to even pinpoint what is problematic for Gentoo here: I can understand that they need to support multiple build backends as a reality of Python packaging and that’s frustrating, but per below it seems extremely unlikely that they actually need to build every single patch version of uv. Nothing about uv’s defaults or the packaging template would require that, and users would have to go out of their way to configure their build backend in that way.

(And note: this is not unique to uv! You can grief anybody who does an sdist build by pinning to a random ancient version of setuptools or any other build backend, including other ones that use native code. This is why uv, like everybody else, encourages semver ranges for build backends.)

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

Sure it does. TFA claims

> all Gentoo users need to build it from source, and given that it’s released quite frequently (12 releases in the 30 days prior to writing this post), that’s a lot of building. Like, for every 100 ms spent running uv-build to install one release of your package, Gentoo users will spend many hours building new uv-build versions over and over again.

And that is false, exactly because of that standard. If you want reproducible builds then you can stick with a previously built version of uv-build for a long time. If you want working builds on the fly using your own processes, then the standard empowers you to substitute something else. If you want to use the Python packaging ecosystem in the normal way, then it doesn't even matter what your distro is.

uv-build is for pure Python projects, which entails that the "build" process is trivial. It doesn't even bytecode-compile the .pyc files generally; wheels aren't expected to contain them (your installer may produce them at install time, or you can let Python produce them on demand). Binary reproducibility for pure-Python wheels is just not, from anything I've seen, a high priority for Python packaging.

Linux distros have these ideas about packaging that are just not suitable for Python and not in tune with what the Python ecosystem is doing. The vast majority of the Python code you install should not be integrated into your "system". (Python devs rarely find themselves wanting to "bootstrap" everything from source, either.) Gentoo's issue here appears to be their own policy, which is a problem of their own making. It's unrealistic for them to expect random Python devs to care about this.

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

If you mean because of Gentoo policy, that's their fault. I can guarantee you that approximately nobody using uv-build is concerned with whether their package makes it into Portage. Python build systems aren't designed to produce packages native to Portage (or any other Linux packaging system). Probably the overwhelming majority of these users aren't expecting any Linux distro repositories to host their package in any form, and probably most of them couldn't even tell you what Gentoo is.

If you mean technically, then no; once you have the source code and are using ebuild, nothing compels you to choose the backend specified in pyproject.toml. If everything is up to standard then it's trivial to switch it over to, say, Flit. Most projects following a standard src layout will need no tool-specific config, and there's quite little of it possible regardless (and all well documented). The author even highlights:

> It’s a backend and the whole point of PEP 517 is that you can use any backend with any tool. You can use flit-core, you can use hatchling, and either of them will work just fine with uv (or any other frontend).

The edits do take time but it's a lot better than the proposed bogeyman of waiting for a new build of uv-build from Rust source.

I think that’s actually a different problem: packages that use uv-build for their backend should use a semver range, which enables the kind of “pick a version and use it” strategy I mentioned before.

(This is the default when you initialize a project with uv, so I think someone would need to go out of their way to configure their build backend to request a specific patch version of uv-build.)

I hear you, but realistically the rustification of Python package internals is only going to strongly increase over the next year (I'm working on a number of such packages, myself), so systematic solutions to such annoyances are going to become increasingly necessary

I mean, SPARC and anything else can work right. But what uv can’t do is conjure up support for platforms that the larger ecosystem won’t even claim to support.

To that extent, I think uv (and CPython, and Rust, and so many other projects) are essentially trying to be honest in saying “we have no way to build and test that to our own standards.” I think that kind of honesty in validation is its own kind of load reduction on the ecosystem, because it means less tacit assumption that the maintainers will support anything that happens to build.

Maybe, but I do think “pure Python sdists could just be a file selector” misses lots of common cases of simple code generation. Documentation boilerplate generators, version-at-runtime generators, things that generate e.g. static HTML or protobuf or whatnot results…it’s not most pure-Python packages, sure, but it’s a lot of them.

Python is exactly as flexible as the people who use it want it to be. I suspect that most trivial solutions do not generalize to the interests of the broader Python community, which is how we end up with standards that are universally agreed to be not exactly what anybody wants.

You can demonstrate it somewhat empirically: pip, uv, etc. all understand the build backend interface and packaging standards and can install any package that conforms with the standards.

(I think so much of the confusion around Python packaging comes down the layer of abstraction/standardization not being the one that users intuitively expect. This is unfortunate and is made worse by lackluster user-facing documentation. But there are standards that guarantee interoperability, and they’re pretty close to Pareto-optimal in terms of making all involved parties happy.)

My somewhat ignorant experience is full of dealing with combinatorial expansion of python build backends and needing to husband them in nixos including all sorts of overrides to deal with, iirc, weird circularities in deps.

With apologies to Slackware, it is the compile-everything-from-source distro.

Happy user for over 23 years now!

Yes, and unlike NixOS they dont calculate build hashes for the sake of making binary caches. So truly, you have to build from source, even if your recipe is exactly the same as everyone else's. I've never really understood this zealotry around compiling things myself, and boy are there some big (slow to compile) programs out there these days.

They basically started it all, that was what made Gentoo different from everyone else.

I'm pretty sure that is the entire purpose of Gentoo

Yeah, it has binary packages nowadays as well, though.

Python build backends are standardized in PEP 517, and packaging metadata is standardized in PEP 621. You can read the actual metadata PEPs for “computed” metadata i.e. the metadata that appears in distributions as well, if you’d like.

(It’s not kind or charitable to call someone a liar.)

> they do request nicely, but they also present the drawbacks for them as if they are absolute, and even claim that "its benefits don’t outweigh the drawbacks".

but who's using it? Where are the hordes of SPARC users craving cutting-edge software?

You registered to post this?

I agree that they exist. My 2c: the wheels in that link of manylinux, musl linux, Windows, and MacOS will work on 99.9% of users' OSs.

Only at the beginning, as someone points out, it doesn't scale to always write a C and Rust versions of new modules.

I found this recently - couldn't compile it on HPUX. Trying to get rust on there would have been an absolute impossibility of course. I can get bash though, and lots of other GNU utilities - all written in C of course. Thank goodness some people care!

People who don't care about HPUX will never care about it but they would if e.g. we decided that only windows and Ubuntu were supported ... except for the windows and ubuntu python users who wouldn't care.

It's I'm-all-right Jack until it's your use case that gets bulleted.

https://blog.nawaz.org/posts/2023/May/20-years-of-gentoo/#an...

> In the early days, there was much promotion of Gentoo as being “faster”, because you could compile everything based on your particular processor, etc. And you could increase the optimization level for a boost. Their web site still touts this as a reason to use Gentoo.

> In reality, the performance is more or less the same as on any other distribution. The folks who stick to Gentoo tend not to care about performance as much. Unfortunately, this perception of Gentoo remains, and I wish they would remove the verbiage from their site.

The vast majority of desktop Linux users run Ubuntu (initial motto: Linux for human beings). So one may argue the literal opposite of what you wrote, in that if Canonical didn't invest into making a Linux distro that's accessible to normal people, it wouldn't have the relevance it now does. On top of that, Linux has (or had) a number of clear advantages over Windows that dwarf the presumed upsides of compiling everything from source vs. downloading builds.

There's not much of an argument for adopting obscure niche practices for their own sake

And the vast amount corporations that invest into it, and related userspace projects like C and C++ compilers, otherwise it would be another GNU Hurd.

The herd of docker containers would in practice share almost nothing apart from the kernel and waste a lot of RAM. Didn't matter when RAM was cheap, but nowadays...

Less and less with the ongoing ads, taskbar issues, and RAM eaating bloatware.

By just adding

          preempt=full 

          sudo rpm-ostree kargs --editor