Skip to content

fix(markers): Fix/change dependency specifiers #1971

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
henryiii wants to merge 3 commits into
base: main
Choose a base branch
from
+16 −10
Open

fix(markers): Fix/change dependency specifiers #1971

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7158046
fix(markers): Fix/change dependency specifiers
henryiii Dec 5, 2025
1c4007d
fix: improve text for comparison rules
henryiii Dec 8, 2025
aeb7062
fix: minor rewording around `==` and sides
henryiii Dec 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 16 additions & 10 deletions source/specifications/dependency-specifiers.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -196,20 +196,26 @@ safely evaluate it without running arbitrary code that could become a security
vulnerability. Markers were first standardised in :pep:`345`. This document
fixes some issues that were observed in the design described in :pep:`426`.

Comparisons in marker expressions are typed by the comparison operator and the
type of the marker value. The <marker_op> operators that are not in
<version_cmp> perform the same as they do for strings or sets in Python based on
whether the marker value is a string or set itself. The <version_cmp> operators
use the version comparison rules of the
:ref:`Version specifier specification <version-specifiers>` when those are
defined (that is when both sides have a valid version specifier). If there is no
defined behaviour of this specification and the operator exists in Python, then
the operator falls back to the Python behaviour for the types involved.
Comparisons in marker expressions are based on the types in the table below.
The variables marked with ``Version`` or ``Version | String`` use the version
comparison rules of the :ref:`Version specifier specification
<version-specifiers>` when those are defined (that is when both sides have a
valid version specifier). If both sides are not expressible as a ``Version``,
then ``==``, ``>=``, and ``<=`` check for exact equality; no ordering is
Copy link
Member

@webknjaz webknjaz Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

``<=`` check for exact equality

Reading that < checks for equality seems odd to me. Perhaps, we should rephrase this?

Copy link
Contributor Author

@henryiii henryiii Dec 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this was implied by "no ordering is assumed" - maybe we could reverse the order?

Or, maybe this - dropping the ==, since it falls under the following line about string operations:

Comparisons in marker expressions are based on the types in the table below. The variables marked with Version or Version | String use the version comparison rules of the Version specifier specification when those are defined (that is when both sides have a valid version specifier). If either side is not expressible as a Version, then >=, and <= only check for exact equality; no ordering is assumed. On other operators, operators perform the same as they do for strings or sets in Python based on whether the marker value is a string or set itself.

Copy link
Contributor Author

@henryiii henryiii Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know how the revised wordign (pushed) is.

assumed. On other operators, operators perform the same as they do for strings
or sets in Python based on whether the marker value is a string or set itself.
Otherwise an error should be raised. e.g. the following will result in errors::

"dog" ~= "fred"
python_version ~= "surprise"

Variables that are marked solely as ``String`` support ``==`` and ``!=``;
ordered comparison operators may also follow same rules as ``Version`` defined
above when not a valid Version, with ``>=`` and ``<=`` being equivalent to
``==``, and ``<`` and ``>`` always evaluating to ``False``. This is legacy
behavior due to an older version of this spec, and tools may choose to warn or
fail if ordered comparisons are used on ``String`` markers.

User supplied constants are always encoded as strings with either ``'`` or
``"`` quote marks. Note that backslash escapes are not defined, but existing
implementations do support them. They are not included in this
Expand Down Expand Up @@ -267,7 +273,7 @@ an error like all other unknown variables.
- ``CPython``, ``Jython``
* - ``platform_release``
- :py:func:`platform.release()`
- String
- Version | String
- ``3.14.1-x86_64-linode39``, ``14.5.0``, ``1.8.0_51``
* - ``platform_system``
- :py:func:`platform.system()`
Expand Down
Loading