Revert pyparsing constraint #482
Conversation
See: https://github.com/pypa/packaging/pull/480/files#r740158146 As suggested by @layday, local `packaging` package directory takes precedence over the installed `packaging`. By building with `pyproject-build`, CWD will not be added to python path.
See discussion in : pypa#480 `pyparsing` is backward compatible for now (synonyms for camel cased attributes). Fix unit test to accecpt either pyparsing 2 or 3 exception message.
|
Awesome, thanks for this PR! Could a new release be tagged with this fix? That would help a ton solving dependency conflicts. |
|
Google app engine deployment fails because of the upper limit so I expect many are facing an issue; a new release would be much appreciated... |
|
I'm going to be releasing a blog post roasting the practice of limiting upper versions constraints in the future; any extra ammo you have from experience would be helpful. :) Also, a new release is not really needed, the current release just needs to be yanked. It wasn't capped before. |
|
The version cap inadvertently prevented breakage on a much larger scale. The latest release of pyparsing removed two private attributes that packaging is using. |
|
What two attributes? Can't find the PR with a quick search. |
|
Please see #483 (comment). |
|
Ah, just found it. That was an update from 3.0.4 to 3.0.5, though; so the correct version constraint would have been <3.0.5 or !=3.0.5 😂. We should not have been using private variables, or we should use our own parser (seems like there's already a PR for that ;) ) |
|
Also, with the version constraint, that breakage in 3.0.5 would not have been discovered so quickly. |
|
Hi Henry
thanks for your support.
Thinking about upper version cap, I find:
* the disadvantages are very clear. One misses security improvements, extra functionality, etc. but most clearly it generates many errors with your users. In my case, I cant update our Google App Engine anymore because I cannot influence the versions of the standard packages.
* Why would one use an upper limit?
* 1. the new version of the package contains new bugs
* 2. the new package has improved security (e.g. prevent using private attributes)
In case 1, its better to fix it in your own package. Either by making a work-around (version specific) or by removing the calls and use your own (parser)
In case 2, it is clear that you have to improve your own package bcoz of improper programming in the past.
Jeroen
…________________________________
From: Henry Schreiner ***@***.***>
Sent: Monday, November 8, 2021 5:31 PM
To: pypa/packaging ***@***.***>
Cc: jeroenbbb ***@***.***>; Comment ***@***.***>
Subject: Re: [pypa/packaging] Revert pyparsing constraint (PR #482)
I'm going to be releasing a blog post roasting the practice of limiting upper versions constraints in the future; any extra ammo you have from experience would be helpful. :)
Also, a new release is not needed, the current release just needs to be yanked. It wasn't capped before.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#482 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIHKVRTHDZVQOKOY3AN7YJLUK73P7ANCNFSM5HGTCJMA>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
This reverts the bump to pyparsing in PRs: build(deps): bump pyparsing from 3.0.4 to 3.0.5 in /tools/dependency #18937 dependabot: Python updates #18929 the pyparsing version is not compatible with the current version of packaging the issue is fixed upstream pypa/packaging#482 but the fix is not yet included in any release this issue is currently causing the github deps checker action to fail Signed-off-by: Ryan Northey <[email protected]>
nox-poetry crashed in the GA workflow when parsing requirements with packaging < 21.1 and pyparsing >= 3 See pypa/packaging#482 for the upstream discussion.
|
Looks like this was fixed in pyparsing 3.0.6. So the correct constraint was !=3.0.5. :) |
|
To echo @EwoutH's comment, could a new release be tagged? This would help dependency conflicts (for example, when using |
|
@johnthagen see #483 for cutting another release. |
See:
#471
#480
This PR removes the upper limit on
pyparsingversion and fixes the unit test to accept the exception message of either version 2 or 3. This seem to be the minimal change needed to support both major versions for now (until the camel case synonyms will be removed).