Markers redux

[dimbleby]

Revisiting #645 (comment). Best reviewed commit by commit

• the first two are some preparatory pedantry noting that a VersionRange might be empty

  • at some point in the drafting of this pull request this case was actually hit
  • seem fairly clearly correct, even if we have managed without this logic until now

• next is the main event: when we see a version constraint <V, PEP440 rules re pre-releases imply that really what this means is <V.dev0

• next fix the issue noted back at Fix for handling of version ranges #645

(>1).union(!=2) ... becomes >1,<2 || >2. ... that's correct as an internal representation, but becomes wrong once re-parsed - it really does want to be written eg in lockfiles as >1,!=2

• finally opt out of this when parsing python versions. Also as mentioned back in Fix for handling of version ranges #645:

there's a distinction between version ranges as used in version requirements, and versions as used in markers / python versions. So as not to break the world it's probably unwise to make changes for the latter two

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• There are now two separate helpers around the <V dev0 semantics (_canonical_strict_max and _display_max_text / _is_canonical_strict_max); consider consolidating or co-locating the canonicalization/display rules so they can’t silently drift apart over time.
• The _range_or_empty helper is only wired into some VersionRange arithmetic paths (e.g. parts of intersect and difference); it’s worth double-checking whether other operations or constructors that can synthesize inverted/coincident bounds should also be routed through it to avoid leaving behind non-normalized empty ranges.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- There are now two separate helpers around the `<V` dev0 semantics (`_canonical_strict_max` and `_display_max_text` / `_is_canonical_strict_max`); consider consolidating or co-locating the canonicalization/display rules so they can’t silently drift apart over time.
- The `_range_or_empty` helper is only wired into some `VersionRange` arithmetic paths (e.g. parts of `intersect` and `difference`); it’s worth double-checking whether other operations or constructors that can synthesize inverted/coincident bounds should also be routed through it to avoid leaving behind non-normalized empty ranges.

## Individual Comments

### Comment 1
<location path="src/poetry/core/constraints/version/version_union.py" line_range="355-357" />
<code_context>
+        # constructor doesn't enforce that, so sort defensively.
+        ranges = sorted(self._ranges)  # type: ignore[type-var]
+
+        groups: list[list[VersionRangeConstraint]] = [[ranges[0]]]
+        for prev, cur in pairwise(ranges):
+            if prev.max is not None and prev.max == cur.min:
+                groups[-1].append(cur)
+            else:
</code_context>
<issue_to_address>
**issue (bug_risk):** Seam detection for punctured ranges ignores inclusivity, which can change semantics (e.g. `<=2 || >2` becomes `!=2`).

The grouping in `_punctured_range_string` currently collapses any adjacent ranges where `prev.max is not None and prev.max == cur.min`, so cases like `<=2 || >2` or `<2 || >=2` are treated as a single punctured range. That makes `_render_punctured_range` emit `!=2`, which wrongly excludes 2 even though the union should include it. To preserve the intended “single-point exclusion” behavior, the grouping condition should also check `not prev.include_max and not cur.include_min`, so only `<V` followed by `>V` is collapsed into a `!=V` puncture.
</issue_to_address>

### Comment 2
<location path="tests/test_factory.py" line_range="1280" />
<code_context>
     dep = Factory.create_dependency("foo", constraint)
     assert dep.python_versions == exp_python
-    assert dep.python_constraint == parse_constraint(exp_python)
+    assert dep.python_constraint == parse_marker_version_constraint(exp_python)
     assert str(dep.marker) == exp_marker

</code_context>
<issue_to_address>
**issue (testing):** Missing targeted tests for `parse_marker_version_constraint` and marker-specific `<V` handling

Switching to `parse_marker_version_constraint` changes behaviour for Python markers, but the tests don’t currently distinguish marker parsing from standard `parse_constraint`. Please add tests that:

* parse a marker constraint like `"<3.8"` via `parse_marker_version_constraint` and assert it renders exactly as `"<3.8"`, and
* confirm that a non-marker constraint with the same text still uses the stricter PEP 440 semantics (i.e. effectively `<3.8.dev0`).

This will lock in the intended non-canonicalizing behaviour for markers and guard against regressions.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Seam detection for punctured ranges ignores inclusivity, which can change semantics (e.g. <=2 || >2 becomes !=2).

The grouping in _punctured_range_string currently collapses any adjacent ranges where prev.max is not None and prev.max == cur.min, so cases like <=2 || >2 or <2 || >=2 are treated as a single punctured range. That makes _render_punctured_range emit !=2, which wrongly excludes 2 even though the union should include it. To preserve the intended “single-point exclusion” behavior, the grouping condition should also check not prev.include_max and not cur.include_min, so only <V followed by >V is collapsed into a !=V puncture.

[sourcery-ai]

issue (testing): Missing targeted tests for parse_marker_version_constraint and marker-specific <V handling

Switching to parse_marker_version_constraint changes behaviour for Python markers, but the tests don’t currently distinguish marker parsing from standard parse_constraint. Please add tests that:

• parse a marker constraint like "<3.8" via parse_marker_version_constraint and assert it renders exactly as "<3.8", and
• confirm that a non-marker constraint with the same text still uses the stricter PEP 440 semantics (i.e. effectively <3.8.dev0).

This will lock in the intended non-canonicalizing behaviour for markers and guard against regressions.