requirements, url: adapt to urllib3 exception type change #1989
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Exirel
approved these changes
Nov 13, 2020
Contributor
Exirel
left a comment
Exirel
left a comment
There was a problem hiding this comment.
Yeah, the lock is fine for now.
dgw
force-pushed
the
urllib3-requirements-safe
branch
from
4ca6b1b to
695750a
Compare
Member
Author
|
Older Python/pip versions didn't like an unrestricted "double" dependency, so I fixed that. No other changes. |
urllib3 1.26 changed its `UnicodeError` to a custom exception type, breaking some of our `url` plugin's tests (plus the real-world behavior they check, of course). Now `urllib3.exceptions.LocationParseError` is raised (a subclass of `urllib3.exceptions.LocationValueError`) instead. The solution is threefold: 1. Distrust urllib3's point releases; pin it to 1.26.x or lower now 2. Catch the custom exception type's superclass now 3. Stop catching `UnicodeError` and drop our support for urllib3<1.26 in Sopel 8 (or switch to urllib3 2.0+ only, if it's released by then)
dgw
force-pushed
the
urllib3-requirements-safe
branch
from
695750a to
fa94bcd
Compare
Member
Author
|
Needed another pin for Python 3.4, because pip apparently can't tell that 1.24.x satisfies both <1.27 (from us) and <1.25 (from requests), and it just installed 1.25.x anyway. |
4 tasks
dgw
added a commit
that referenced
this pull request
Nov 14, 2020
This is a backport of #1989 onto Sopel's maintenance branch, to ensure that fresh installations continue to go smoothly. Original commit message follows. ---- urllib3 1.26 changed its `UnicodeError` to a custom exception type, breaking some of our `url` plugin's tests (plus the real-world behavior they check, of course). Now `urllib3.exceptions.LocationParseError` is raised (a subclass of `urllib3.exceptions.LocationValueError`) instead. The solution is threefold: 1. Distrust urllib3's point releases; pin it to 1.26.x or lower now 2. Catch the custom exception type's superclass now 3. Stop catching `UnicodeError` and drop our support for urllib3<1.26 in Sopel 8 (or switch to urllib3 2.0+ only, if it's released by then)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
urllib3 1.26 changed its
UnicodeErrorto a custom exception type, breaking some of oururlplugin's tests (plus the real-world behavior they check, of course). Nowurllib3.exceptions.LocationParseErroris raised (a subclass ofurllib3.exceptions.LocationValueError) instead.The solution is threefold:
UnicodeErrorand drop our support for urllib3<1.26 in Sopel 8 (or switch to urllib3 2.0+ only, if it's released by then)Checklist
make qa(runsmake qualityandmake test)Notes
Probably will backport this to 7.0.x and cut a new release. Don't want to touch that branch any more, but I think it's going to be impossible to get a working new Sopel install on v7.0.6 because of this change.