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

idna 2.8 released #4890

Closed
Nothing4You opened this issue Dec 5, 2018 · 9 comments
Closed

idna 2.8 released #4890

Nothing4You opened this issue Dec 5, 2018 · 9 comments

Comments

@Nothing4You
Copy link

Nothing4You commented Dec 5, 2018

idna 2.8 was just released. requests is pinned to idna>=2.5,<2.8

Can the pin be updated to allow v2.8?

@Vlad-Shcherbina
Copy link

By the way, out of curiosity, what's the reason to pin minor version number at all?
It seems it was first introduced in 1ea27b3, but there is no explanation in the commit metadata.

@sigmavirus24
Copy link
Contributor

@Vlad-Shcherbina why have a lowest version we support? Because that's the lowest version we know works with idna at all. Libraries change things in subtly backwards incompatible ways. If we don't put together a range of known good versions, users will use whatever they want, shoot themselves in the foot, and demand we fix it for them. With only 2 people working on this project, no one has time for that

@asvetlov
Copy link

asvetlov commented Dec 5, 2018

My 2 cents.

aiohttp library depends on yarl. In turn, yarl depends on idna>=2.0.
So far so good.
aiohttp uses twine check for making sure that setup.py is (at least partially) correct.
There is no surprise that twine uses the awesome requests (almost every tool that needs synchronous HTTP access uses requests).

Today our daily CI job has failed wit version conflict error. Sure, we can create a separate virtual env for twine usage or we can find another solution but the situation looks odd.

On another hand I understand the striving to pin everything for such community important project: any backward incompatibility in requests dependencies can hurt too many people.

@asvetlov
Copy link

asvetlov commented Dec 5, 2018

Could you please make a new release?
Releasing requests==2.20.2 should not take too long perhaps.

@sigmavirus24
Copy link
Contributor

Releasing requests==2.20.2 should not take too long perhaps.

Changing version constraints would lead to a 2.21 version. There's already a PR for upgrading the dependency version #4889

@Schamschula
Copy link

Breaks py-requests, and in turn certbot under MacPorts.

@nateprewitt
Copy link
Member

Hi @Schamschula, we’re aware of the impact. Using the requirements specified by Requests will continue to work until the next patch is released. I’m aiming to get something out early next week once we can get the testing issues worked out.

@Schamschula
Copy link

@nateprewitt Thanks for the update.!

In the meantime, I've opened a ticket for those MacPorts users that might run into this issue:

https://trac.macports.org/ticket/57747

@nateprewitt
Copy link
Member

Requests 2.21.0 is up on PyPi now supporting idna 2.8.

ssbarnea pushed a commit to ssbarnea/molecule that referenced this issue Jan 31, 2019
carver added a commit to carver/trinity that referenced this issue Jul 7, 2020
This is the correct requests version according to:
psf/requests#4890 (comment)
carver added a commit to carver/trinity that referenced this issue Jul 7, 2020
This is the correct requests version according to:
psf/requests#4890 (comment)
carver added a commit to carver/trinity that referenced this issue Jul 7, 2020
This is the correct requests version according to:
psf/requests#4890 (comment)
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants