Allow user to constrain supported lock environments (#6210)

## Summary

The strategy here is: if the user provides supported environments, we
use those as the initial forks when resolving. As a result, we never add
or explore branches that are disjoint with the supported environments.
(If the supported environments change, we ignore the lockfile entirely,
so we don't have to worry about any interactions between supported
environments and the preference forks.)

Closes https://github.com/astral-sh/uv/issues/6184.
This commit is contained in:
Charlie Marsh 2024-08-20 09:28:04 -04:00 committed by GitHub
parent d02c202eb2
commit 3395d24959
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
28 changed files with 790 additions and 49 deletions

View file

@ -51,7 +51,7 @@ called a re-validation request.
A re-validation request includes with it some metadata (usually an "entity tag"
or `etag` for short) that was on the cached response (which is now stale).
When we send this request, the server can compare it with its most up to date
When we send this request, the server can compare it with its most up-to-date
version of the resource. If its entity tag matches the one we gave it (among
other possible criteria), then the server can skip returning the body and
instead just return a small HTTP 304 NOT MODIFIED response. When we get this