uv/scripts/scenarios
Charlie Marsh 6333823236
Change the definition of --locked to require satisfaction check (#6102)
## Summary

This PR changes the definition of `--locked` from:

> Produces the same `Lock`

To:

> Passes `Lock::satisfies`

This is a subtle but important difference. Previous, if
`Lock::satisfies` failed, we would run a resolution, then do
`existing_lock == lock`. If the two weren't equal, and `--locked` was
specified, we'd throw an error.

The equality check is hard to get right. For example, it means that we
can't ship #6076 without changing our marker representation, since the
deserialized lockfile "loses" some of the internal marker state that
gets accumulated during resolution.

The downside of this change is that there could be scenarios in which
`uv lock --locked` fails even though the lockfile would actually work
and the exact TOML would be unchanged. But... I think it's ok if
`--locked` fails after the user modifies something?
2024-08-15 08:17:28 -04:00
..
templates Change the definition of --locked to require satisfaction check (#6102) 2024-08-15 08:17:28 -04:00
.gitignore Only textwrap json packse scenarios with packse 0.3.32 (#5810) 2024-08-08 15:49:50 +02:00
generate.py Only textwrap json packse scenarios with packse 0.3.32 (#5810) 2024-08-08 15:49:50 +02:00
requirements.in Update packse to 0.3.34 (#5954) 2024-08-09 09:04:17 +00:00
requirements.txt Update packse to 0.3.34 (#5954) 2024-08-09 09:04:17 +00:00