fix parsing Windows server platform_release

[radoering]

Resolves: python-poetry/poetry#10710

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

Summary by Sourcery

Relax version parsing to support additional non-PEP 440 platform release formats while preserving strict validation by default.

Bug Fixes:

• Fix parsing of Windows Server-style platform_release values when non-PEP 440 versions are explicitly allowed.

Tests:

• Extend marker version constraint tests to cover additional invalid and non-PEP 440 platform release patterns, including Windows Server-style versions.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Adjusts version parsing patterns and tests so that Windows Server-like platform_release strings (e.g. '2022Server') are rejected by default as invalid marker constraints but can be parsed when non‑PEP 440 parsing is explicitly requested, aligning behavior with existing non-standard versions like '4.9.253-tegra'.

Flow diagram for version parsing with updated release pattern

flowchart LR
    VersionString["Input version string"] --> ModeCheck{PEP440 parsing?}

    ModeCheck -- Yes --> Pep440Parser["PEP440Parser"]
    Pep440Parser --> Pep440Match{Matches PEP440?}
    Pep440Match -- Yes --> Pep440Valid["Accept version as valid PEP440"]
    Pep440Match -- No --> Pep440Invalid["Reject as invalid marker constraint (e.g. 2022Server)"]

    ModeCheck -- No (non PEP440) --> NonStandardParser["NonStandardVersionParser"]
    NonStandardParser --> ApplyPattern["Apply RELEASE_PATTERN with optional sign before build"]

    ApplyPattern --> ReleaseGroup["Match release group: [0-9]+(.[0-9]+)*"]
    ReleaseGroup --> OptionalBuild{Build part present?}

    OptionalBuild -- No --> NonPep440ValidRelease["Accept plain numeric releases"]

    OptionalBuild -- Yes --> BuildGroup["Match build group: [0-9a-zA-Z-]+(.[0-9a-zA-Z-]+)*"]
    BuildGroup --> SignOptional["Optional + or - before build (e.g. 4.9.253-tegra)"]
    SignOptional --> NonPep440Valid["Accept as valid non PEP440 version"]

Loading

File-Level Changes

Change	Details	Files
Extend marker version parsing tests to cover both Tegra-style and Windows Server-style non-PEP 440 versions, parameterizing valid/invalid cases.	Convert tests for invalid marker version constraints to a parameterized test that checks multiple invalid constraint strings raise ParseConstraintError by default. Convert tests for allowing invalid marker versions when pep440=False into a parameterized test that verifies parsing of multiple non-standard versions, including Windows Server style strings. Adjust assertions to construct Version objects from parameter tuples, keeping the local version segment as the last element.	tests/constraints/version/test_parse_constraint.py
Relax the version release pattern so that build segments after the release component are treated as optional separators, allowing parsing of platform_release strings like '2022Server' when requested.	Update the RELEASE_PATTERN regular expression so the plus/minus separator before the build component is optional rather than mandatory. Keep the existing rules for allowed characters and dot-separated segments in the build component while broadening what inputs match the pattern.	src/poetry/core/constraints/version/patterns.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
python-poetry/poetry#10710	Ensure Poetry does not raise ParseConstraintError when encountering Windows Server style platform_release values like 2025Server during dependency resolution on Windows runners.	❌	The issue arises when environment markers are validated using parse_marker_version_constraint with its default pep440=True (as seen in the stack trace from markers.py -> parse_marker_version_constraint). The PR only changes the RELEASE_PATTERN and associated tests, but still treats "2022Server" (and by analogy "2025Server") as invalid when pep440=True. There is no change wiring platform_release markers to call the parser with pep440=False, so the environment marker validation path that currently raises ParseConstraintError remains unchanged and the original failure mode is not clearly resolved by this PR alone.
python-poetry/poetry#10710	Add tests to cover parsing of Windows Server style version strings (e.g. 2022Server) in marker version constraints, including both PEP 440–strict and relaxed parsing modes.	✅

---

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 left some high level feedback:

• Making the '+'/'-' separator optional in RELEASE_PATTERN broadens what will be parsed as a build segment (e.g. 1.0abc), so it would be good to double‑check that this still matches the intended grammar and doesn’t unexpectedly change behavior for other version shapes.
• In test_parse_marker_constraint_does_allow_invalid_version_if_requested, the expected tuple plus *expected[:-1] and type: ignore[misc] is a bit opaque; consider constructing the Version explicitly per case or using a small helper to avoid the ignore and make the mapping from input to expected Version clearer.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Making the '+'/'-' separator optional in `RELEASE_PATTERN` broadens what will be parsed as a build segment (e.g. `1.0abc`), so it would be good to double‑check that this still matches the intended grammar and doesn’t unexpectedly change behavior for other version shapes.
- In `test_parse_marker_constraint_does_allow_invalid_version_if_requested`, the `expected` tuple plus `*expected[:-1]` and `type: ignore[misc]` is a bit opaque; consider constructing the `Version` explicitly per case or using a small helper to avoid the ignore and make the mapping from input to expected `Version` clearer.

---

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.}