Add option to prefer locked versions of packages in build environments

[zanieb]

Adds a new build-dependency-strategy = latest | prefer-locked setting. latest is the current behavior. prefer-locked will prefer to use locked versions of runtime dependencies for build dependencies when they match. This is intended to work with #14735 to allow adding torch as an extra build dependency for flash-attn and prefer using the same version as you would at runtime (that's what flash-attn requires, but it's usually achieved by disabling build isolation).

The name is prefer-locked because I want to add a future option... like require-locked which will error if the versions matching the runtime versions cannot be used. The naming here is actually a little awkward, because it'll be confusing when we introduce locking of build dependencies separately from runtime requirements (which is on the roadmap). We might want to do... latest | try-match-runtime | match-runtime? I'm not sure. I also expect that we'll want a package-level variant of this setting, as match-runtime might be too aggressive for most packages. I also find this setting a little awkward alongside #14735, I wonder if we want a dedicated build dependencies section?

[konstin]

We can make this stronger by saying that the locked version will be used, if a single locked version exists in the lockfile, and if it doesn't cause any conflicts during resolution. (Though the latter isn't about the version being unfulfillable, but about whether it conflicts with higher priority packages in the resolution, which I hope is a detail users won't run into with build deps, and for which require-locked will help)

[zanieb]

I tried to capture this a little in 9a91e91

[konstin]

I like the prefer-locked name, it captures what it does concisely.

[zanieb]

@geofft has pointed out an important concern, that since these preferences are not taken into account in the wheel cache key, you won't automatically get a rebuild of a package when your locked version of a build dependency changes; or, worse, if you have another project with a different locked version, they'll share the same cached wheel :/

[zanieb]

This is still "preferring" the locked version, but it sounds problematic. I'm not sure what the workaround is yet.

[konstin]

@geofft has pointed out an important concern, that since these preferences are not taken into account in the wheel cache key, you won't automatically get a rebuild of a package when your locked version of a build dependency changes; or, worse, if you have another project with a different locked version, they'll share the same cached wheel :/

This is the same logic we apply today without preferences: We build wheels once, and then cache them forever, even if the resolution of the package's build deps changes. For supporting caching with different version ranges, we need to support multiple builds with the same tag for a package in the cache, attach the build deps versions to it and select only fitting ones installation. A criteria could be whether the versions fit tool.uv.extra-build-dependencies.

[charliermarsh]

This is the same logic we apply today without preferences: We build wheels once, and then cache them forever, even if the resolution of the package's build deps changes. For supporting caching with different version ranges, we need to support multiple builds with the same tag for a package in the cache, attach the build deps versions to it and select only fitting ones installation.

Yeah, I guess it doesn't seem that much worse than what we have today. Is it worth? We could look at caching separate builds based on build dependencies as a second step, right?