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

requirements, url: adapt to urllib3 exception type change #1989

Merged
merged 1 commit into from
Nov 14, 2020

Conversation

dgw
Copy link
Member

@dgw dgw commented Nov 13, 2020

Description

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)

Checklist

  • I have read CONTRIBUTING.md
  • I can and do license this contribution under the EFLv2
  • No issues are reported by make qa (runs make quality and make test)
  • I have tested the functionality of the things this change touches

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.

@dgw dgw added the Build label Nov 13, 2020
@dgw dgw added this to the 7.1.0 milestone Nov 13, 2020
@dgw dgw requested a review from a team November 13, 2020 23:46
Copy link
Contributor

@Exirel Exirel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the lock is fine for now.

@dgw dgw force-pushed the urllib3-requirements-safe branch from 4ca6b1b to 695750a Compare November 14, 2020 00:38
@dgw
Copy link
Member Author

dgw commented Nov 14, 2020

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 dgw force-pushed the urllib3-requirements-safe branch from 695750a to fa94bcd Compare November 14, 2020 01:49
@dgw
Copy link
Member Author

dgw commented Nov 14, 2020

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.

@dgw dgw merged commit b25eb93 into master Nov 14, 2020
@dgw dgw deleted the urllib3-requirements-safe branch November 14, 2020 06:03
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
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants