> if build backend versions change so often and projects don't pin a specific version but just say "use the latest"

This isn’t what’s happening: uv defaults to semver bounds, so a maintainer would have to go out of their way to introduce a troublesome backend constraint.

And note: there is no “use the latest” constraint in Python packaging. If you leave the build backend version unconstrained, the build frontend is allowed to resolve any version it sees fit, including the version it already has.

(I also know from first-hand experience that Gentoo and other distributions do not build Python packages as-is; they patch them in all kinds of ways. But that’s neither here nor there.)

▲

pdonis an hour ago | parent [-]

> uv defaults to semver bounds

But a new patch release will be within the same semver bound, so it amounts to the same thing.

> If you leave the build backend version unconstrained, the build frontend is allowed to resolve any version it sees fit, including the version it already has.

What do build frontends actually do, though?

▲

woodruffw an hour ago | parent [-]

> But a new patch release will be within the same semver bound, so it amounts to the same thing.

Sorry, can you lay out the actual problem you’re envisioning for me? If uv-build goes from 0.13.1 to 0.13.2, then anybody with a semver bound of `uv-build>=0.12,<0.14` doesn’t need to update anything. They can keep using whatever version of the build backend they already have that satisfies that bound.

The main thing that would be troublesome is if a user pins their build backend to a specific range or version, e.g. `uv-build==0.13.1`. Then, upon bumping it, everyone who has already built 0.13.1 will need to invalidate and rebuild their build backend. But that’s why that isn’t the default.

> What do build frontends actually do, though?

uv will definitely use a compatible version. It won’t even download a copy of that that compatible version by default, since the uv binary itself is typically compatible and can invoke the build backend directly.

I’m not sure what pip and others do, but I would expect they do the same. It’s the obvious way to implement backend resolution.

▲

pdonis 32 minutes ago | parent [-]

> It’s the obvious way to implement backend resolution.

If a compatible version is already present, yes, a frontend can just use it if it's within the semver range specified.

But in many cases, builds are done in a fresh virtual environment that has nothing installed. In such a case, the only option is to download the latest version that's in the semver range specified. That's how the "build" frontend works, for example, unless you specify a flag to keep it from creating a fresh virtual environment.

	▲	woodruffw 2 minutes ago \| parent [-]
		Is that what Gentoo is doing here? I thought the whole point of the distro doing any sort of Python packaging is that they can pierce abstractions like virtual environments where it suits them. (But also: if we’re talking virtual environments then we’re firmly in Python land, not distro land, where the correct answer is “use a wheel” instead of building it yourself.)