-
Notifications
You must be signed in to change notification settings - Fork 245
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
Requirement parser does not support arbitrary equality in legacy parentheses format #336
Comments
The issue is that this operator matches everything after it that is not whitespace as the version:
You'd need to do this instead::
See here: packaging/packaging/specifiers.py Lines 328 to 338 in 59e1488
I'm not sure this is a bug. |
I’d say it is. |
The behavior @uranusjr's suggesting makes sense to me and IMO if the standards say otherwise, we should update them. |
I'm facing this issue while installing the wheel that built with arbitrary equal for dependency in
As I understand pep440 correctly, arbitrary equality is using not only for "escape hatch", but also for comparing versions without taking into account local versions (https://www.python.org/dev/peps/pep-0440/#arbitrary-equality) which may be useful and should not break |
Gental ping since this is surfaced in pip again recently. #353 is a reasonable fix to this IMO. |
Hello, any news on this ? |
I don’t think anyone is actively working on this. Feel free to dive into the parser code. |
Well the question is related to the fact you indicate #353 is a reasonable fix for this so I was wondering if there were plans to merge it ? |
Probably not, I guess? I don’t have permissions to merge PRs here and can’t definitely answer this. The change is reasonable, but far from perfect. The correct logic should only detect the opening parenthesis after the package identifier, and remove the closing one only if there is an opening parenthesis at the correct location. This is likely doable with some parser logic changes, but I have not looked into actually trying it myself. This is very low priority, to be honest. |
Ok, I might take a look at the open PR and try to iron it out Cheers |
#353 is a PR to fix this. Does the approach seem reasonable to people? |
Now that we have a hand-crafted parser, I’d actually expect it be able to handle parenthesis-matching directly. |
#624 does that updating, and makes it possible to use this format. ❯ echo 'name(===arbitrarystring)' | python -c "from packaging.requirements import Requirement; print(vars(Requirement(input())))"
{'name': 'name', 'url': None, 'extras': set(), 'specifier': <SpecifierSet('===arbitrarystring')>, 'marker': None}
❯ echo ' name ( === arbitrarystring ) ' | python -c "from packaging.requirements import Requirement; print(vars(Requirement(input())))"
{'name': 'name', 'url': None, 'extras': set(), 'specifier': <SpecifierSet('===arbitrarystring')>, 'marker': None} |
These all work as expected:
But not this:
>>> Requirement('foo (===1.0)') Traceback (most recent call last): File "packaging/requirements.py", line 98, in __init__ req = REQUIREMENT.parseString(requirement_string) File "pyparsing.py", line 1955, in parseString raise exc File "pyparsing.py", line 3814, in parseImpl raise ParseException(instring, loc, self.errmsg, self) pyparsing.ParseException: Expected stringEnd, found '(' (at char 4), (line:1, col:5) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "packaging/requirements.py", line 100, in __init__ raise InvalidRequirement( packaging.requirements.InvalidRequirement: Parse error at "'(===1.0)'": Expected stringEnd
The text was updated successfully, but these errors were encountered: