Discard insufficient fork markers

[konstin]

In #10669, a pyproject.toml with requires-python but no environment had a lockfile covering only a subset of the requires-python space:

resolution-markers = [
    "python_full_version >= '3.10' and platform_python_implementation == 'CPython'",
    "python_full_version == '3.9.*'",
    "python_full_version < '3.9'",
]

This marker set is invalid, we have to reject the lockfile. (We can still use the versions though, to avoid churn).

Part 1/2 of #10669

[charliermarsh]

Once discarded, do we just produce the same lockfile anyway? (If so, does this actually fix anything?)

[konstin]

That's the other half of #10669: the lockfile we're seeing is invalid, it doesn't cover all possible environments. We should never produce a lockfile in this state (fixing #10669), this new branch is error recovery from a buggy state.

This PR exists because i minimized #10669 to this problem by keeping the lockfile, while we still need to fix the problem where we produce this lockfile starting from a pyproject.toml.

[charliermarsh]

Ok. My question is: does this actually produce the correct lockfile? Or even with this change, are we still producing the incorrect lockfile after invalidating?

[konstin]

If checked that when running uv sync on attrs' uv-lock branch, we warn and fix the markers in the lockfile.

There are two ways to create the lockfile:

A)

git switch uv-lock
uv-this-pr sync

B)

git switch uv-lock
rm uv.lock
uv-this-pr sync

(A) has a slightly larger diff to uv-lock than (B) because we collapse e.g. zipp 3.20.2 and zip 3.21.0 into only zipp 3.20.2. I think this is acceptable for an error recovery branch.

[charliermarsh]

I'll tweak and merge this.

[charliermarsh]

I'm a little nervous about this change but don't really have better ideas on how to validate it.

[konstin]

What do think about this? We check that the fork marker coverage is correct for the entire test suite.