Implementation of swapped marker order

[pf_moore (Paul Moore)]

@ncoghlan

I could certainly turn it into a PEP, but given the intent is to not actually change anything , I’m not sure what the PEP could say beyond “Spec confusing, therefore, clarify spec”.

That PR is OK without a PEP (as was established via the thread that it came from). What I was referring to was the more significant changes @konstin was suggesting. Specifically, in terms of the comment

@konstin

This problem is about imprecisions in the current spec. Both from the text and spirit of PEP 508, you can reasonably argue for either behavior.

IMO, a PEP would be needed to establish consensus on the “right” interpretation in cases like these. We might be able to get agreement via a simple discussion thread, but it’s notoriously difficult to be sure what was agreed on without someone writing it down explicitly (and that’s basically what a PEP is).

[konstin (konsti)]

From my perspective, writing a text clarification PR (such as Attempt to clarify environment marker evaluation by ncoghlan · Pull Request #1988 · pypa/packaging.python.org · GitHub) and writing a full PEP (with format, editing, core dev sponsor, submission, pre-merge iterations, approval, separate DPO thread, and then finally still the packaging.python.org PR, which may require clarifications different than the PEP) are a massive difference in burden, especially if the alternative is making an (undocumented) decision at tool level.

[pf_moore (Paul Moore)]

In practical terms I agree. This is a problem with the PEP process, unfortunately.

However in principle, the process necessary to get approval for a text clarification PR, when that PR will change interoperability rules, should be very similar. There’s still a need for discussion on DPO, which would require a clear description of the precise changes being proposed. What constitutes “approval” for a change to be PR-only isn’t clear in the process document, but in practice it’s always been a combination of community consensus and PEP-delegate approval.

Maybe the process could be improved. The SC is already looking at the PEP process, and I hope the Packaging Council will look at the standards process. But those are long-term changes, and in the meantime I view my role as that of a caretaker for the existing process - doing my best to make it as painless as possible while making sure it’s followed properly.

In this particular case, my concern with a PR-based approach is that it’s very easy, once approval for semantic changes has been given, for the PR to suffer from “scope creep”, making more changes than were covered in the discussion, and hence exceeding the authority given. A clear description of the precise changes to be made avoids that - and once you have that plus community consensus, you’re most of the way to a PEP, and I’ll happily expedite as much of the rest of the PEP process as I can.

[guido (Guido van Rossum)]

You could have two PRs. One that is uncontroversial, doing inly minor edits. A second one that resolves the ambiguity in the current PEP. That one should be approved by the SC, after a dpo discussion leads to a clear interpretation.

[ncoghlan (Alyssa Coghlan)]

Aye, I think the two step approach would definitely be viable for the reversibility clarifications:

• a PR-only update that adds descriptive MAY (and potentially SHOULD NOT) guidance that encompasses the behaviour of both packaging and uv (and potentially poetry, as I believe that uses its own specifier parsing logic)
• if it seems useful, a PEP that strengthens the wording to MUST/MUST NOT and actually restricts the marker syntax to enforce the non-commutative nature of the comparisons

It’s entirely plausible that the pragmatic interoperability implications of the first step may prove sufficient to make the second step redundant.

[guido (Guido van Rossum)]

Why does the second step (if needed) need a whole PEP? I’m pretty sure in the past a PR approved by the SC was sufficient.

[pf_moore (Paul Moore)]

It might not. The key here is to get a clear interpretation and community consensus that the interpretation is OK. Our process allows for the decision there to be “make it as a text-only change” or “take it through the PEP process”.

The hard part is writing up the proposed change precisely and getting consensus. The PEP process feels to me like it’s mostly just admin beyond that^[1]. Others seem to feel differently, though

---

1. Of course, part of the PEP process is checking that the proposal is precise enough, so I guess if people hope to get a roughly worded proposal accepted, the PEP process is annoyingly unforgiving… ↩︎

[henryiii (Henry Schreiner)]

We looked at this (@danyeaw and I) at PyCon (the US one, not EuroPy, I’m slow) during the sprints, and there are several complications I wasn’t aware of before, but I think the data from PyPI indicates it’s not actually used.

• Packaging does support reversed markers in the same places uv does.

It turns out even though it’s coded to only call SpecifierSet on the right side, it happens to work to compare backwards as long as the left hand side doesn’t have something that has to be a specifier, like .* in it (the reported bug). So Yoda expressions work today in packaging as long as it’s a certain subset of the operations. It’s not intentional, but it partially works.

This is really annoying, as I was thinking packaging didn’t support this at all. However, I got a recent download of PyPI metadata, and scanned all 1,478,875 (43,222 unique) marker requirements. There are no examples of Yoda conditions at all (except "x" in thing, of course, but that’s valid and not part of what we are wanting to tighten).

• The grammar in the spec is really loose

Okay, kind of knew that one, but really weird stuff is allowed, like "a" < "b", extra >= "dev", etc. I think some of this was to keep the grammar short. Dan started with a clarification on this in Clarify dependency specifiers extra special cases in the grammar by danyeaw · Pull Request #2054 · pypa/packaging.python.org · GitHub. There are no examples of other comparisons on extra in the dataset. There are no examples of string-string or variable-variable comparisons.

• == → 1,462,072 instances
• != → 31 instances (18 distinct packages)
• anything else → 0

Related, there are 61 uses of ===, all on versions. They are not used for markers, etc.

I’d propose, due to the low impact, we tighten each one of these separately in PRs to packaging.python.org, like the one above. We could bundle them all into a “tighten marker specification” PEP if that’s seen as preferable.

This would unblock the work on markers in packaging. Dan can fill in anything I forgot. Data is at Release 2026.07.21 · sethmlarson/pypi-data · GitHub (thanks @sethmlarson!).

[danyeaw]

Hi @henryiii, I really like that plan! We also opened Clarify that comparisons must have an environment variable and a string literal by danyeaw · Pull Request #2055 · pypa/packaging.python.org · GitHub