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

Add support for urllib3 2.2.1 #3138

Closed
brodycj opened this issue Feb 20, 2024 · 10 comments · Fixed by #3141
Closed

Add support for urllib3 2.2.1 #3138

brodycj opened this issue Feb 20, 2024 · 10 comments · Fixed by #3141
Labels
dependencies This issue is a problem in a dependency. feature-request This issue requests a feature.

Comments

@brodycj
Copy link

brodycj commented Feb 20, 2024

Describe the bug

Underlying botocore requires outdated urllib3 version:

  • 1.x in case of Python pre-3.10
  • < 2.1 in case of Python 3.10(+)

background from: #2926

I do totally understand the motivation for these outdated urllib3 version dependencies. IMHO I think it should be up to whoever uses boto3 to specify whether or not to use an outdated version of urllib3.

Incidentally I am using this for an application that may run on Amazon Linux, which may need the older urllib3 dependency, would have preferred to make this choice myself.

I am taking liberty to file this issue for boto3, no objections if maintainers want to transfer this to botocore.

I am also taking liberty to leave out some info that I think should not matter - please post a loud holler if any further info is needed. Thanks in advance!

Expected Behavior

I think it should be possible to install boto3 and another package such as requests with recently updated version of urllib3 such as urllib3 == 2.2.1.

Current Behavior

Combinaiton of boto3 == 1.34.46 & urllib3 == 2.2.1 leads to pip installation error.

Reproduction Steps

see above - please post a loud holler if any further info is needed

Possible Solution

No response

Additional Information/Context

No response

SDK version used

Python 3.9 / 3.11; boto3 v1.34.46

Environment details (OS name and version, etc.)

Ubuntu 22.04.3 LTS 64-bit (with some customized updates) on Intel core i7

@brodycj brodycj added bug This issue is a confirmed bug. needs-triage This issue or PR still needs to be triaged. labels Feb 20, 2024
@nateprewitt nateprewitt added dependencies This issue is a problem in a dependency. feature-request This issue requests a feature. and removed bug This issue is a confirmed bug. needs-triage This issue or PR still needs to be triaged. labels Feb 21, 2024
@kaleb-keny
Copy link

God please yes!

Collecting urllib3<1.27,>=1.25.4 (from botocore<1.35.0,>=1.34.48->boto3<2,>=1.9.253->watchtower)
  Using cached urllib3-1.26.18-py2.py3-none-any.whl.metadata (48 kB)

I keep having to do this

pip install watchtower --no-dependencie
pip install boto3 --no-dependencie
pip install botocore --no-dependencie

@nateprewitt nateprewitt changed the title outdated urllib3 version required by underlying botocore Add support for urllib3 2.2.1 Feb 23, 2024
@nateprewitt
Copy link
Contributor

Hi everyone, just to reiterate what was discussed in the original issue since it was left out of the description. Botocore cannot support urllib3 2.0 on Python <3.10, this is covered in the urllib3 docs as well. There are no plans currently to change that as it would result in broad impact for AWS customers until they manually pin themselves.

For Python 3.10+, urllib3 2.2.0 had breaking changes that were impacting botocore until the most recent release on Saturday (Feb 17). We're currently reviewing the latest version to confirm there are no other subtle breakages and will update this ticket once we have a clear path to moving the pin. Thanks for your patience!

@brodycj
Copy link
Author

brodycj commented Feb 23, 2024

One more thing is that the application I am working on also uses requests, which uses urllib3 in turn. I continue to wish that botocore could leave this up to the higher-level application. This was part of my original reqeust.

P.S. Yes I do totally understand the need to keep the functionality stable, avoiding breaking changes from underlying modules such as urllib3. But there will be users who would rather avoid using outdated versions, especially if they may affect any other libraries. I guess this is a situation we cannot avoid given the design of Python & PIP installations.

@nateprewitt
Copy link
Contributor

Just to clarify, Requests has no requirements to update to urllib3 2.0, it's compatible with both the 1.x and 2.x branches. urllib3 1.26.x is still actively maintained and is receiving continued releases for the foreseeable future.

But yes, you're right, a lot of the defensiveness in our pins is due to how Python's packaging infrastructure works. Without the pins we'd have had ~4-5 large scale breakages for boto3 which is the most downloaded python package. In the rare occassions those do happen, it's felt across a large portion of the python ecosystem. We have to weigh safety over total flexibility since there are breakages with a major version bump in dependencies.

@ThiefMaster
Copy link

Can't you just vendor urllib3?

@nateprewitt
Copy link
Contributor

Can't you just vendor urllib3?

The short answer is no. We already vendored urllib3 for years (botocore>=1.0.0,<=1.12.253) before ultimately removing it from botocore and similarly, was removed from Requests. The primary downsides are size and longevity of releases. Once there's a vulnerability in urllib3, every version of botocore with an older vendored copy becomes either an active security risk or wasted space on PyPI. Keeping the two projects separated allows for more flexibility in choices, as well as not requiring us to make a release for customers to patch their systems.

The other major issue is the size of botocore. While already large, adding vendored dependencies further increases overall size and create problems when packaged for Lambda. The downsides of vendoring outweigh the majority of the benefits which we already have empirical data on. While it's unfortunate we may not have same day parity with new releases, the trade off is stability at the expense of a moderate delay.

@robd003
Copy link

robd003 commented Mar 12, 2024

Why not have botocore 1.x for ancient Python versions and botocore 2.x for all the modern cool kids who stick with active stable releases and actually maintain their code base?

@nateprewitt
Copy link
Contributor

Thanks for the feedback, @robd003. To make sure we're on the same page, all versions of urllib3 we support are actively maintained, stable releases. urllib3 1.x is still receiving updates and we're currently ~3 weeks behind on the first stable release of urllib3 for 2.x beyond what we currently support.

Major versioning botocore would make this packaging problem considerably worse. Anyone using the AWSCLI, PynamoDB, Boto3, aiobotocore, or s3fs in conjunction would start breaking with a new major version and you'd still have a urllib3 pin somewhere in that set. We'd also be detracting time from fixing this issue in the current major version of botocore by having to maintain multiple variants of this package. There's no tangible benefit to the end user in that setup.

Thanks for your continued patience while this is addressed.

Copy link

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

@nateprewitt
Copy link
Contributor

To follow up, this was resolved in today's release (botocore 1.34.63) with #3141. Users on Python 3.10+ should be free to control their urllib3 2.x requirements going forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies This issue is a problem in a dependency. feature-request This issue requests a feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants