A plea not to use uv-build

To copy my response on Lobsters:

(I am one of uv’s maintainers.)

The nice thing about Python packaging is that it’s standardized: 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.

With that said, 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?

(For context: the only reason uv-build releases as often as it does is because it’s easier to keep its internals in lockstep with the rest of uv. But you can do a normal version bound in your Python build backend metadata and uv will happily use whatever version of uv-build is already present.)

By a search, Gentoo accounts for less than 1% of all developers. If uv-build is more conformant to people, probably volunteers (and if they're using it, it probably is), I don't think the Gentoo people have any right to want them not to use it because it makes their lives harder. They can request, and 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".

> the Gentoo uv ebuild already carries two hacks to make it possible to build uv on 32-bit platforms).

https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/uv...

Looks like it's being built with fat LTO by default (and gentoo patched to thin LTO). Which is fine if you want to spend CI cycles once to ship executables to thousands of users. If you compile from source and run the tool maybe once then they should consider going further and run with maybe opt-level=1, lto=off; halfway between release and debug. This is how rustc itself builds some internal buildtools that get recompiled frequently relative to how often they run.

I'm not sure that skipping SPARC is a bad thing. Who even has SPARC machines sitting around to validate builds? Even Fujitsu moved to ARM for their later cores.

UV build is distributed as a binary/executable, e.g. manylinux wheels on pypi: https://pypi.org/project/uv-build/#files. If a user or distro's conventions are to build things from source, this is a consequence they have implicitly accepted. For the vast majority of computer users and uses, installing binaries makes more sense.

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

If only there were ways to skip this waste...

maybe it's time to embrace the enemy and go "clanker, this is uv-build source, rewrite it in portable C". rewrite it in C FTW!

btw, I know of a guy who using extensive amounts of tokens to make his fork of mrustc usable via "claude, make this rustc compile 99% of crates.io", I think this also can yield some results.

I don't think I agree with the author's assessment here:

> The other reason is performance and that argument makes even less sense. Even if it mattered, we’re realistically talking about a difference in the ballpark of 100 ms, for an action executed rarely; it is equally possible that any gain will be outweighed by the time needed to fetch the 1.5 MiB wheel for uv-build.

Modern CI architectures are building Docker stacks from scratch and using a readthrough cache of wheels. Downloading may still be the dominant factor, but the second-dominant factor does start to add up, especially when the downloading gets cached at various layers.

Wait until he discovers that CPython is actually taking Rust in, see recent PyCon talks on the matter.

Maybe it's time to grow up and download binary builds like a normal person. I had my 'let's compile the linux kernel from source for 3.5% hypothetical performance gains' phase but you can't expect professional devs to cater to source-obsessed hobbyists