fix creation of python_version markers from constraints with one digit (e.g. ">3,<4", "3.*")

[radoering]

Resolves: python-poetry/poetry-plugin-export#354

• Added tests for changed code.
• Updated documentation for changed code.

Summary by Sourcery

Fix normalization of python_version markers for single-component and wildcard version constraints and update related marker intersection behavior.

Bug Fixes:

• Correct handling of python_version equality and inequality markers with one-digit versions (e.g. "3", "3.*") when normalizing to constraint ranges.
• Adjust normalization of python_version range markers using <= and > so that generated upper and lower bounds correctly reflect the intended version intervals and do not produce empty constraints.

Tests:

• Expand unit tests for dependency PEP 508 generation to cover additional python_version patterns including major-only and wildcard versions and combined constraints.
• Add marker parsing and intersection tests for python_version ranges involving major-only bounds to verify correct normalization and combination behavior.
• Update existing tests for constraint creation from python_version markers to reflect the corrected normalization logic for comparisons against major-only versions.

[sourcery-ai]

Reviewer's Guide

Adjusts normalization of python_version markers so single-digit constraints (e.g. '3', '3.*', '>3', '<=3') are expanded to correct version ranges, and extends tests to cover these semantics and marker intersections.

File-Level Changes

Change	Details	Files
Normalize bare major python_version equality/inequality markers by first converting them to a major.minor form before expanding to range or wildcard constraints.	In normalize_python_version_markers, when op == '==' and version has no dot, append '.0' before transforming into a '~' constraint so '==3' becomes '~3.0' which yields '>=3.0,<4.0' markers. In normalize_python_version_markers, when op == '!=' and version has no dot, append '.0' before expanding to '.' so '!=3' becomes '!=3.0.'. Keep the logic for '<=', '>', '<', '>=' but rely on Version precision handling to always advance to the next minor, removing the precision == 2 guard so single-digit versions use the same path.	src/poetry/core/packages/utils/utils.py
Update and extend tests around python_version marker generation and normalization, especially for single-digit and wildcard constraints.	Replace the specific to_pep_508 test that hardcoded '~2.7

Assessment against linked issues

Issue	Objective	Addressed	Explanation
python-poetry/poetry-plugin-export#354	Generate correct python_version markers for major-only wildcard constraints (e.g. python-versions == "3.*") so they no longer export as python_version == "3" but as a proper range (e.g. python_version >= "3" and python_version < "4").	✅
python-poetry/poetry-plugin-export#354	Normalize and interpret python_version markers involving single-digit/major-only constraints (e.g. ">3", "<=3", "==3") consistently so that marker intersection and conversion logic behave correctly.	✅

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

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

• The logic that appends '.0' for one-digit python_version constraints is duplicated for both '==' and '!=' branches; consider extracting this into a small helper (e.g., _normalize_major_only_version(version)) to make the intent clearer and avoid future divergence.
• The transformation of python_version > "3" into a constraint starting at >=3.1 is subtle; adding an inline comment in normalize_python_version_markers explaining why 3.0 is intentionally excluded would help future maintainers understand the reasoning behind this behavior.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The logic that appends '.0' for one-digit python_version constraints is duplicated for both '==' and '!=' branches; consider extracting this into a small helper (e.g., `_normalize_major_only_version(version)`) to make the intent clearer and avoid future divergence.
- The transformation of `python_version > "3"` into a constraint starting at `>=3.1` is subtle; adding an inline comment in `normalize_python_version_markers` explaining why `3.0` is intentionally excluded would help future maintainers understand the reasoning behind this behavior.

## Individual Comments

### Comment 1
<location> `tests/packages/test_dependency.py:128-133` </location>
<code_context>
         ("<3.5.4", 'python_full_version < "3.5.4"'),
         (">=3.5.4", 'python_full_version >= "3.5.4"'),
         ("== 3.5.4", 'python_full_version == "3.5.4"'),
+        ("==3.*", 'python_version >= "3" and python_version < "4"'),
+        (
+            "~2.7 || ^3.6",
</code_context>

<issue_to_address>
**suggestion (testing):** Add a test case for a bare major-range python constraint (e.g. ">=3,<4") turned into markers

The new parametrized cases for `python_versions` already cover `==3.*` and `~2.7 || ^3.6`. To better match the PR’s focus on single-digit constraints, please also add a case where `python_versions` is a bare major range (e.g. `">=3,<4"`) and assert that `to_pep_508()` produces the corresponding `python_version` marker. This will confirm that normalized ranges like `>=3,<4` are translated correctly, not just the `==3.*` shorthand.

```suggestion
        ("== 3.5.4", 'python_full_version == "3.5.4"'),
        ("==3.*", 'python_version >= "3" and python_version < "4"'),
        (">=3,<4", 'python_version >= "3" and python_version < "4"'),
        (
            "~2.7 || ^3.6",
            'python_version == "2.7" or python_version >= "3.6" and python_version < "4.0"',
        ),
```
</issue_to_address>

### Comment 2
<location> `tests/packages/utils/test_utils.py:180-189` </location>
<code_context>
         ('python_version == "3.6"', "~3.6"),
         ('python_version == "3.6.*"', "==3.6.*"),
         ('python_version == "3.6.* "', "==3.6.*"),
+        ('python_version == "3"', ">=3.0,<3.1"),
+        ('python_version == "3.*"', ">=3,<4"),
         # !=
         ('python_version != "3.6"', "!=3.6.*"),
         ('python_version != "3.6.*"', "!=3.6.*"),
         ('python_version != "3.6.* "', "!=3.6.*"),
         # <, <=, >, >= precision 1
         ('python_version < "3"', "<3"),
-        ('python_version <= "3"', "<3"),
-        ('python_version > "3"', ">=3"),
+        ('python_version <= "3"', "<3.1"),
+        ('python_version > "3"', ">=3.1"),
         ('python_version >= "3"', ">=3"),
         # <, <=, >, >= precision 2
         ('python_version < "3.6"', "<3.6"),
</code_context>

<issue_to_address>
**suggestion (testing):** Extend coverage for major-only python_version comparisons, especially "!=" and mixed inequalities

To better exercise the new major-only handling, consider adding a few more parametrized cases:

* `python_version != "3"` → `"!=3.*"`, to mirror the equality case and verify `!=` with a major-only version.
* A range like `'>="3.0"'` with `'<="3"'` to confirm dotted vs single-digit upper bounds are treated consistently.
* (Optional) A whitespace variant for a major-only case, similar to the existing `"3.6.* "` entries, to confirm trimming still applies.

These would strengthen coverage of the normalization logic for single-digit versions across all operators.

Suggested implementation:

```python
        ('python_version == "3.6"', "~3.6"),
        ('python_version == "3.6.*"', "==3.6.*"),
        ('python_version == "3.6.* "', "==3.6.*"),
        ('python_version == "3"', ">=3.0,<3.1"),
        ('python_version == "3.*"', ">=3,<4"),
        # !=
        ('python_version != "3.6"', "!=3.6.*"),
        ('python_version != "3.6.*"', "!=3.6.*"),
        ('python_version != "3.6.* "', "!=3.6.*"),
        ('python_version != "3"', "!=3.*"),
        ('python_version != "3 "', "!=3.*"),
        # <, <=, >, >= precision 1
        ('python_version < "3"', "<3"),
        ('python_version <= "3"', "<3.1"),
        ('python_version > "3"', ">=3.1"),
        ('python_version >= "3"', ">=3"),
        # mixed range with major-only upper bound
        ('python_version >= "3.0" and python_version <= "3"', ">=3.0,<3.1"),
        # <, <=, >, >= precision 2
        ('python_version < "3.6"', "<3.6"),

```

If the test suite represents compound marker expressions differently (for example, using separate parameters or a different string format than `"python_version >= \"3.0\" and python_version <= \"3\""`), adjust that case to match the surrounding style. Also, if your normalization collapses the lower bound for `>= "3.0"` to `>=3`, you may need to update the expected string to `">=3,<3.1"` instead of `">=3.0,<3.1"`.
</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.}