Personally, I'm against integrating anything backed by corporate interest as a central dependency for an ecosystem. It should be self-supporting, as the interests of the company can and will change at any time, rather than being organised specifically to support the ecosystem as a whole.
Doesn't that massively limit your options for software dependencies though?
There are open source projects that have firm, non-single-corporate governance - Python, Django, PostgreSQL, Node.js are good examples of those. But that's a pretty thin group.
It does. I also recognise the reality that many projects are primarily corporate-backed, and that there's little I can do about that. I'm stating a preference, not a dietary restriction.
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.)
With that said, I don’t understand why Gentoo needs to rebuild every single release of uv-build.
Good question - I'm not sure what Gentoo's policy is about fast-moving dependencies like this. It had also made me wonder if uv-build was bundled with uv (which would make reducing its update frequency less of an option), but I see they do have a separate package for it.
Given there is a separate uv-build release per uv build, it may just not be clear to them how frequently they need to update it. Official guidance for external packagers telling them "it's okay to only update this every N days" seems like it could help out in this situation.
Yeah, uv comes with uv-build baked in, so the majority of builds shouldn’t even require a separate build backend fetch (assuming they’re using a semver-compatible version of uv-build).
That’s a good point about documentation! I’ll see what we currently have there; I believe we already document the semver range recommendation but we might also be able to expand it to downstream distribution advice. I suppose the tricky thing there will be finding “one size fits most” language since AFAICT other from-source distributions don’t have exactly the same problem.
One thing not mentioned is the config APIs for those other build backends can be lacking/frustrating depending on what you're doing. I remember a while back, I had the worst time trying to get hatchling to include files in the package that were generated, but gitignore'd. Otherwise a solid post, I didn't really think about uv_build from a distro package maintainer's POV. I'm not really sold that Python packages should be in those repos, but that's their prerogative.
That refers to the fact that a developer running the uv build frontend could be picking any build-backend and it would work, regardless of if it's flit-core or uv-build or whichever. But the backends themselves can have different implicit behaviour (and different configurations), so someone building the project later usually can't just one-line patch the build-backend to another one that they would prefer.
It's a problem for Gentoo's users, and it is also a (perhaps lesser) problem for any Linux distribution that offers support for architectures that don't have Rust or don't have a Rust implementation capable of building uv_build. (As is described in the blog post.)
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.
I wonder how long that will hold, with Python 3.16 planning to start using Rust. It'll probably remain optional for a good few versions, but the writing is on the wall.
It seems bad to advocate that we shouldn’t have nice thing across a variety of mainsteam and not-so-mainstream systems in order to support legacy CPUs that are now of retrocomputing hobby interest or that 32-bit targets should remain self-hosting when pretty much all software development takes place of 64-bit platforms.
It would be nice if there was a pure python fallback for uv-build. There are definitely some situations where it's not possible to use the uv build backend today (micropip for instance).
I don't like the author's idea that build performance doesn't matter because it only has a positive effect on developers, and affects negatively Gentoo users
addison | 3 hours ago
Personally, I'm against integrating anything backed by corporate interest as a central dependency for an ecosystem. It should be self-supporting, as the interests of the company can and will change at any time, rather than being organised specifically to support the ecosystem as a whole.
simonw | 3 hours ago
Doesn't that massively limit your options for software dependencies though?
There are open source projects that have firm, non-single-corporate governance - Python, Django, PostgreSQL, Node.js are good examples of those. But that's a pretty thin group.
addison | 3 hours ago
It does. I also recognise the reality that many projects are primarily corporate-backed, and that there's little I can do about that. I'm stating a preference, not a dietary restriction.
erock | 37 minutes ago
Its not limiting when you experience a rug pull, its a liability. Limitations can be empowering and spark creative solutions. I’m all for it
yossarian | 3 hours ago
(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.)
misty | an hour ago
Good question - I'm not sure what Gentoo's policy is about fast-moving dependencies like this. It had also made me wonder if uv-build was bundled with uv (which would make reducing its update frequency less of an option), but I see they do have a separate package for it.
Given there is a separate uv-build release per uv build, it may just not be clear to them how frequently they need to update it. Official guidance for external packagers telling them "it's okay to only update this every N days" seems like it could help out in this situation.
yossarian | 20 minutes ago
Yeah, uv comes with uv-build baked in, so the majority of builds shouldn’t even require a separate build backend fetch (assuming they’re using a semver-compatible version of uv-build).
That’s a good point about documentation! I’ll see what we currently have there; I believe we already document the semver range recommendation but we might also be able to expand it to downstream distribution advice. I suppose the tricky thing there will be finding “one size fits most” language since AFAICT other from-source distributions don’t have exactly the same problem.
maximilian | 6 hours ago
One thing not mentioned is the config APIs for those other build backends can be lacking/frustrating depending on what you're doing. I remember a while back, I had the worst time trying to get
hatchlingto include files in the package that were generated, but gitignore'd. Otherwise a solid post, I didn't really think aboutuv_buildfrom a distro package maintainer's POV. I'm not really sold that Python packages should be in those repos, but that's their prerogative.sunshowers | 4 hours ago
Then surely Gentoo can apply patches pointing to another build backend?
nekopsykose | 3 hours ago
That refers to the fact that a developer running the
uv buildfrontend could be picking any build-backend and it would work, regardless of if it's flit-core or uv-build or whichever. But the backends themselves can have different implicit behaviour (and different configurations), so someone building the project later usually can't just one-line patch the build-backend to another one that they would prefer.sunshowers | 2 hours ago
Ah, I see. Thanks. Well, I guess I don't think this is really anybody else's problem but Gentoo's.
jzb | an hour ago
It's a problem for Gentoo's users, and it is also a (perhaps lesser) problem for any Linux distribution that offers support for architectures that don't have Rust or don't have a Rust implementation capable of building
uv_build. (As is described in the blog post.)moltonel | 3 hours ago
I wonder how long that will hold, with Python 3.16 planning to start using Rust. It'll probably remain optional for a good few versions, but the writing is on the wall.
masklinn | 3 hours ago
Gentoo is well aware, they've already expressed worry about this on the pre-PEP thread (https://discuss.python.org/t/pre-pep-rust-for-cpython/104906/70).
hsivonen | 2 hours ago
It seems bad to advocate that we shouldn’t have nice thing across a variety of mainsteam and not-so-mainstream systems in order to support legacy CPUs that are now of retrocomputing hobby interest or that 32-bit targets should remain self-hosting when pretty much all software development takes place of 64-bit platforms.
mitsuhiko | 6 hours ago
It would be nice if there was a pure python fallback for uv-build. There are definitely some situations where it's not possible to use the uv build backend today (micropip for instance).
realkc | 4 hours ago
I don't like the author's idea that build performance doesn't matter because it only has a positive effect on developers, and affects negatively Gentoo users