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