Quick Answer
uv corrects how it reads an always-false dependency marker after serialization. A condition that cannot match a Python version now retains that meaning when converted back into its internal representation.
In Plain English
Dependency markers attach conditions to packages, such as installing something only on a particular platform. A resolver may simplify an impossible condition into a standard textual form. Saving and reloading it should not change the logic.
Code Evidence
The marker algebra handles the minimum release version explicitly: python_version below zero becomes false, and a greater-than-or-equal comparison against zero becomes true. A new round-trip test serializes the false marker and parses it again. Other cases verify simplification with a Windows-platform condition and distinguish python_version from fuller version fields.
Why It Matters
For a lockfile, logical stability matters as much as readable text. Our interpretation is that this correction protects a basic contract: a stored condition should mean the same thing after a reload. It is not a new Python release constraint that application developers need to add manually.
Serialization Is Part of the Logic
A dependency resolver often moves between an internal representation and text stored in a file or displayed to another component. The text is not merely decoration: when it is read again, it becomes an input to later decisions. An always-false condition must remain false across that boundary, or the stored form has changed the meaning of the dependency graph.
This patch addresses a specific boundary value in the python_version marker. The reviewed algebra recognizes a comparison below the minimum release version as false and the corresponding greater-than-or-equal comparison as true. Those constant results let the internal logic represent the impossible or universal condition consistently. The accompanying round-trip test is especially important because it exercises the route through text rather than only the original in-memory value.
Why a Constant Condition Appears
An application author does not need to type an impossible Python constraint for a resolver to encounter one. Logical operations can simplify combinations of conditions into a constant result. For example, analysis of mutually incompatible requirements may leave a branch that cannot apply. This is a general explanation of marker algebra, not a claim about a particular project's lockfile in the regression.
A Lockfile Review Scenario
Consider a team that regenerates dependency information, commits it, and later loads it on another machine. The team expects the stored conditions to describe the same set of applicable environments at both points. A condition that is impossible should not become a live branch simply because it was written out and reconstructed.
That scenario explains the significance of the patch without asserting that every lockfile was affected. The relevant trigger is the marker form and the conversion path, not merely the presence of a lockfile. A project with no such condition may show no visible change. Likewise, a changed dependency result after an upgrade could have many other causes, so this fix should be used as a concrete lead rather than a blanket explanation.
Keep the Version Fields Distinct
The tests also distinguish python_version from python_full_version and implementation_version. Similar names can invite a tempting but unsafe generalization: if a simplification works for one field, apply it to all of them. The reviewed cases instead preserve separate semantics for those fields. An explanation of this patch should retain that boundary rather than advertise a universal rule about every version comparison.
The Windows-platform simplification case provides another useful perspective. Version conditions can interact with other marker terms, so the meaning of a constant result matters inside a larger expression as well as on its own. The test coverage described here connects the corrected boundary handling with that combination. It does not establish exhaustive coverage of every platform, operator, or compound marker.
How to Validate a Suspected Round-Trip Problem
Begin with the smallest marker expression that exhibits the unexpected change and record the uv version. Preserve the expression exactly, including its field names and operators. Compare its meaning before serialization with its meaning after parsing, using the upstream regression as a guide to the intended invariant. If the concern comes from a project file, retain a minimal copy so unrelated dependency updates do not obscure the result.
For a project-level check, compare the relevant dependency decisions under the same interpreter and platform conditions. Then vary only the environment needed to test the marker branch. A successful installation in one environment cannot by itself demonstrate that an impossible branch stays impossible everywhere. Conversely, a changed textual rendering may still be logically equivalent, so inspect the decision it represents instead of treating formatting changes as a failure.
These are suggested validation steps; we did not run the resolver or reconstruct a failing project. The strongest evidence available here remains the explicit boundary handling and the new round-trip assertion. Together they support a focused reliability improvement: an internal false marker can pass through its serialized form without losing its meaning.
An Open Question
Why not apply the same shortcut to every version field? The added tests specifically avoid equating python_full_version and implementation_version with this case. Readers should preserve those distinctions instead of generalizing from similarly named fields.
Scope and Limitations
We inspected the algebra and tests but did not run the resolver. The scope is marker interpretation; the patch is not evidence of a broad change to dependency selection for every project.