Andrew Gallant 3d4f0c934e Fix handling of changes to requires-python (#14076) ... When using `uv lock --upgrade-package=python` after changing `requires-python`, it was possible to get into a state where the fork markers produced corresponded to the empty set. This in turn resulted in an empty lock file. There was already some infrastructure in place that I think was perhaps intended to handle this. In particular, `Lock::check_marker_coverage` checks whether the fork markers have some overlap with the supported environments (including the `requires-python`). But there were two problems with this. First is that in lock validation, this marker coverage check came _after_ a path that returned `Preferable` (meaning that the fork markers should be kept) when `--upgrade-package` was used. Second is that the marker coverage check used the `requires-python` in the lock file and _not_ the `requires-python` in the now updated `pyproject.toml`. We attempt to solve this conundrum by slightly re-arranging lock file validation and by explicitly checking whether the *new* `requires-python` is disjoint from the fork markers in the lock file. If it is, then we return `Versions` from lock file validation (indicating that the fork markers should be dropped). Fixes #13951		2025-06-17 11:50:05 -04:00
..
src	Fix handling of changes to requires-python (#14076)	2025-06-17 11:50:05 -04:00
Cargo.toml	Add DisplaySafeUrl newtype to prevent leaking of credentials by default (#13560)	2025-05-27 00:05:30 +02:00