So every Gentoo user that has a Python project that uses uv-build ends up having to rebuild uv-build, and then every Python project they have that uses it, every time uv-build pushes an update.
Other distros don't necessarily have quite the same problem because, if they include packages of Python projects, they don't normally track the build backend as a dependency. So if uv-build pushes an update, the distro would push an updated package for uv-build, but they wouldn't look at every Python project they package to see if it used uv-build as a build backend and rebuild it if it did. It's the "rebuild from source every time" aspect of Gentoo that forces that connection.
my take on linux distros being annoyed by their own policies is that perhaps they should change the policy. in this case, perhaps they should pretend uv-build updates once a month or something.
for example, they seem to be fine doing a quick sed on pyproject.toml (https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/pa...) or patching stuff for compat (https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/as...)
This is what i mean when it seems typical for a distro to monkey around with packages and/or their build system. These were just the first two packages i clicked on in dev-python. maybe others are "pure upstream", but there's definitely the capability here to just... not have the problem?
That's my understanding, yes.
Thing is, that apparently won't work. From [0], with some more discussion starting at [1]
> > 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.
So, would it be correct to decide that package with an unconstrained version gets built with 0.1.0? And when that fails to build, what's the distro packager to do? Bang on the package maintainer until they specify the real constraint? Yeah, good luck with that.
Doesn't it make way more sense to assume that "unconstrained uv-build version" means "they only tested this with the very latest version of uv-build" and proceed accordingly? This will fail sometimes, but I figure it'll fail far less often then assuming that you get to use 0.1.0 if no version is specified.
I'm being a little extreme with my example here, but only to illustrate the larger point I'm making. Breaking changes do happen, and without specified version constraints one has to assume that "very latest available" is the correct one.
(There are all kinds of legitimate reasons to use an unconstrained dependency, including locking it separately and also trying to help other downstream Linux distros with their own bespoke packaging problems.)
> that’s why you should use a semver range, as is the default, instead of leaving it unconstrained
gentoo appears to support exactly 7 versions of uv-build, a list they update by hand: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/uv...
git changelog of uv-build in the gentoo package manager: https://gitweb.gentoo.org/repo/gentoo.git/log/dev-python/uv-...
gentoo also wrap python packages in their own package manager, packages in this tree appear to come from their upstream version control system eg Github, not PyPI.
just because someone on hn said something, doesn't make it true.
I don't follow. This feels like Gentoo is mishandling build-tool dependencies.
Does Gentoo also recompile every C/C++ library in the dependency tree every time GCC pushes a minor version bump?
I don't either. I used to run Gentoo for quite a few years in the past and build dependency updates would not trigger rebuilds of build-dependent packages.
Rebuilding the entire system with a new GCC was recommended by the documentation, but there was nothing in Portage forcing it. Neither would you rebuild the system if, e.g. make got an update.
I would say it's doing what it believes is necessary for the Python ecosystem. The build backend is an explicit part of the specification of a Python project.
> Does Gentoo also recompile every C/C++ library in the dependency tree every time GCC pushes a minor version bump?
No, because C/C++ libraries don't have an explicit specification of the build tool to be used in their project, the way a Python project does.
Nothing in the Python spec forces Gentoo to invalidate the downstream package every time build-system dependencies update - that's a behaviour they've decided is correct on their own.
> C/C++ libraries don't have an explicit specification of the build tool to be used in their project
They don't have a standard way to specify such, but they have an implicit dependency on the installed compiler toolchain, and it would be just as valid to interpret "no way to specify a build-system dependency" as "always rebuild" when the build tool updates
Nothing in the Python spec guarantees that the resulting build artifact will be identical if the build system dependencies update but nothing else in the project does. So what's a "build everything from source" distro to do? If it's possible that updating the build dependency will change the build artifact, doesn't it have to rebuild?
With this framing, exactly the same thing can be said about libstdc++, for example, so must we also force a full system recompile on every GCC/clang version bump?