Skip to content
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.

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

Correctly handle non-normalised specifiers in requirements #634

Merged
merged 3 commits into from
Dec 8, 2022

Conversation

pradyunsg
Copy link
Member

Closes #629

@pradyunsg
Copy link
Member Author

Actually, strictly speaking, f6fd2e6 (#634) is enough to fix #629.

Using the exact same patterns as `Specifier` helps ensure that the
same parsing behaviour is seen for specifiers on their own as well as
specifiers within requirements.
This ensures that a non-greedy match still preferentially matches the
longer format.
This validates that the specifier is parsed correctly.
@pradyunsg pradyunsg enabled auto-merge (rebase) December 8, 2022 23:11
@pradyunsg pradyunsg force-pushed the fix-requirements-specifier branch from f4e16dc to 946989c Compare December 8, 2022 23:12
@pradyunsg
Copy link
Member Author

Thanks @brettcannon for the review! ^>^

@pradyunsg pradyunsg merged commit c20074d into pypa:main Dec 8, 2022
@pradyunsg pradyunsg deleted the fix-requirements-specifier branch December 8, 2022 23:12
@brettcannon
Copy link
Member

Thanks @brettcannon for the review! ^>^

Thank good timing that I happened to be going through my GitHub notifications right around when you published this PR. 😁

@frostming
Copy link

Verified, it fixed the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

22.0: The new requirement parser doesn't handle unnormalized specifiers
3 participants