Michał Górny

After seeing yet another dozen packages lose keywords on Gentoo because of a single key dependency switching to uv-build, I would like to plea on behalf of Gentoo users: please don’t use uv-build as a build backend. Just to be clear, this is not about uv itself or any other Astral tools; these are good tools with a nice and responsive upstream. The uv-build backend is one thing we have to disagree on. I’m not saying it’s bad; I’m saying that its benefits don’t outweigh the drawbacks.

What are the drawbacks? It’s really big and it’s written in Rust. Rust has many advantages, but none of them really matter for a build backend that is used to build pure Python packages. 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) and it has no benefit over using a small pure Python backend (say, flit-core whose wheel is 45 KiB). It means that 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.

However, build times aren’t the biggest problem; portability is. You can run Python pretty much anywhere where you can get a working C compiler. Some minor features may not work, but the core is reasonably portable. The list of platforms supported by Rust is growing slowly, and even if you can get a working Rust compiler on a given platform, uv may not work. The problems can range from bugs in the lot of packages that uv depends on (for example, rustix::fs and its dependencies skipping SPARC, for no apparent reason), to the resulting executable being so big that the toolchain runs out of address space (and unlike system memory, you can’t really add address space to a system; the Gentoo uv ebuild already carries two hacks to make it possible to build uv on 32-bit platforms). And then, if your platform is not supported at all… well, let’s just say that adding and maintaining a new platform is a full-time job that may involve a lot of swearing at the code churn.

What about the advantages? Well, I’m aware of two reasons to use uv-build. One is consistency with using uv for your project, and it doesn’t really matter. 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 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. But it doesn’t matter, because realistically the backend is only used by project developers, contributors, CI/CD workflows, downstream packagers and users of source distributions; all regular users use wheels instead. Of these groups, source distribution user group is the largest and the most impacted, and any performance gain is defeated by the time spent building uv-build.

Bumping packages is one of the most common tasks of a Gentoo developer. It shouldn’t then be surprising that it is the one most asking for some kind of automation, and that the pkgbump script would be one of the first scripts to become a part of the mgorny-dev-scripts package.

Today’s pkgbump have come a long way from the trivial script of its first iteration. The most recent versions finally feature the feature I desired for a long time: version manipulation. This also made it possible for the script to become a complete version bumping tool rather than just a part of a larger workflow. In this post, I’d like to shortly tell the story behind the changes, and demonstrate the new options.
Continue reading “pkgbump: from a dumb tool to an irreplaceable helper”

I joined Gentoo over 15 years ago. I was a university student back then. I had lots of free time and energy. I was enthusiastic about novelties, and wanted to push them into Gentoo. Back then, bleeding edge was what I wanted out of it. Today, I have different priorities. I have less time to deal with breakage, and I want my Gentoo stable. I’m becoming somewhat wary of changes, and I find preserving what’s great about Gentoo more important than adding new stuff. And what’s really great about Gentoo is that it can accommodate both personas.

Gentoo has changed over these 15 years too. However, its core principles remained the same, and only recently I realized what they really are. The core value of Gentoo is respect. All the building from source, all the choice and flexibility, and all the community building power is because of this: Gentoo respects you. It doesn’t try to waggle the dog, it just does what you tell it do. It may warn you that you’re having a very bad idea and nobody will help you if you proceed, but in the end, you are free to pursue it.

However, respect goes beyond providing a working distribution for our users. It’s in providing a reasonably vanilla development environment for software authors. It’s in submitting patches upstream to ensure that everyone gets bug fixes. But most importantly, it lies in appreciating the human craft rather than taking the easy way out. And I believe that rejecting LLMs is important to keeping the Gentoo community whole and respected.

These days, I mostly handle Python packaging in Gentoo, build Distribution Kernels and a variety of odds and ends. I try to balance involvement in interesting high-level projects and the necessary ground work. I am employed at Quansight PBC where my work also primarily orients around Python packaging, but involving conda-forge and upstream work; it does not conflict with my Gentoo duties.

Multiple times in the past I’ve been thinking of how Gentoo is perceived by the wider public, the non-users. What probably stands out most is compiling. Almost everyone who heard of Gentoo knows it has something to do with compiling everything. And why are we doing that? Well, besides being hardcore, the common sentiment goes for performance. So yeah, Gentoo users must be some kind of hardcore ricers who try to squeeze every last bit of their system performance.

To be honest, I don’t think that’s a good way to describe Gentoo. Yes, compiling is at the core of it. But performance? I don’t think so, at least not in the obvious, -O9999 -fzomg-fast way. The world has moved on, CPUs have gotten faster, optimizations have gotten smarter, and distributions have started optimizing more aggressively. Optimization-wise, I suspect your average Ubuntu package with generic optimizations may be no slower than the equivalent Gentoo package fine-tuned for your CPU. And if it’s not, then it probably won’t make a real difference anyway.

There’s much more to Gentoo than that. Yes, some of it comes from building from source: the flexibility. But a lot of it comes from the wider Gentoo philosophy, the philosophy that brought us all together. The idea that Gentoo is the distribution we’re making for ourselves and people who enjoy Gentoo. So if I were to make a few arguments for Gentoo, I’d focus on that. And this is what I’d like to do here.

Continue reading “Why Gentoo?”