Allow case insensitive marker evaluation

[jeroendecroos]

Closes #507

Not sure if this is the ideal way to solve the problem, but I've run the ´nox -s tests-3.10´ tests and they all pass, including the new tests to demonstrate the bug.

[brettcannon]

I don't know this code well enough to do a review right now, but do note that linting failed.

[jeroendecroos]

Linting is now passing, I assume that the other check will pass again, but I'll double check tomorrow.

[jeroendecroos]

All checks passed

[pradyunsg]

This would deviate from what PEP 508 states:

Comparisons in marker expressions are typed by the comparison operator. The <marker_op> operators that are not in <version_cmp> perform the same as they do for strings in Python. The <version_cmp> operators use the PEP 440 version comparison rules when those are defined (that is when both sides have a valid version specifier). If there is no defined PEP 440 behaviour and the operator exists in Python, then the operator falls back to the Python behaviour.

The behaviour of == should not be changed in the manner being proposed here.

IIUC, the motivation here is similar to what is being discussed in https://discuss.python.org/t/7614/ -- and the resolution will likely go down the same path as that discussion. x-ref pypa/pip#10889 as well.

---

Two GitHub workflow notes:

• Please don't mention issue numbers in PR titles or commit messages. They result in spam on the original issue, especially when rebasing.
• I've editted the PR description, to add "Closes Should markers ignore case when comparing packages? #507" -- https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

[uranusjr]

Note that marker casing should no longer be a problem with metadata version 2.3 because PEP 685 mandates the extras must be normalised in both sides of the marker expression.

[brettcannon]

@jeroendecroos did you want to try and resolve the merge conflicts and address the comment from Pradyun? And is this still a concern with the changes made to support PEP 685?

[jeroendecroos]

Hi @brettcannon

I saw that 53dbb25 should provide the functionality required.

I've ran my tests with only those changes and the test has passed. I think the tests added in that commit should be sufficient to verify my use case so we can close this PR and ticket according to me.