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 v2 #719

Merged
merged 1 commit into from
Apr 22, 2024
Merged

Add support for urllib3 v2 #719

merged 1 commit into from
Apr 22, 2024

Conversation

iherasymenko
Copy link
Contributor

Description

Allows using urllib3 v2 if Python version is >= 3.10. The same technique is applied in https://github.com/boto/botocore/pull/3141/files.

Issues Resolved

#628

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@saimedhi
Copy link
Collaborator

Hello @iherasymenko, thank you for your contribution. Could you kindly include a few pertinent tests, please?

@dblock
Copy link
Member

dblock commented Apr 16, 2024

Maybe we can introduce an integration test that uses each version of the lib?

@@ -54,7 +54,8 @@
if package == MODULE_DIR or package.startswith(MODULE_DIR + ".")
]
install_requires = [
"urllib3>=1.26.18, <2",
'urllib3>=1.26.18,<1.27 ; python_version < "3.10"',

Choose a reason for hiding this comment

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

Why <1.27 rather than <2? Surely we want those who cannot use urllib3 2.x to at least get updates to 1.x?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This also mirrors what botocore did. I believe the original rationale was that 1.27 may introduce some breaking changes.

@@ -54,7 +54,8 @@
if package == MODULE_DIR or package.startswith(MODULE_DIR + ".")
]
install_requires = [
"urllib3>=1.26.18, <2",
'urllib3>=1.26.18,<1.27 ; python_version < "3.10"',
'urllib3>=1.26.18,!=2.2.0,<3 ; python_version >= "3.10"',

Choose a reason for hiding this comment

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

Why the specific exclusion of 2.2.0?

Copy link
Contributor Author

@iherasymenko iherasymenko Apr 18, 2024

Choose a reason for hiding this comment

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

This mirrors what botocore did. 2.2.0 has some breaking changes.

boto/botocore#3141

boto/botocore#3138 (comment)

@james-certn
Copy link

Naive and hardline thinking: why preserve backward urllib3 compatibility in opensearchpy at all? If someone is tied to an old version of urllib3, they can use an older version of opensearchpy.

I get the desire for flexibility and supporting the most users possible, giving the latest to all users - but at some point the overhead isn't worth it, surely.


That aside, how would one best test this PR's changes in opensearchpy?

@dblock
Copy link
Member

dblock commented Apr 17, 2024

Naive and hardline thinking: why preserve backward urllib3 compatibility in opensearchpy at all? If someone is tied to an old version of urllib3, they can use an older version of opensearchpy.

I get the desire for flexibility and supporting the most users possible, giving the latest to all users - but at some point the overhead isn't worth it, surely.

That's all there is to it, flexibility. Generally if something is possible we tend not to break it to reduce downstream pain. If there's a good reason not to, or it's too hard to maintain, then we can drop it.

That aside, how would one best test this PR's changes in opensearchpy?

Since we're explicitly saying that we support multiple incompatible dependencies I think we need to introduce some way of doing integration tests where one vs. another version of the library is loaded. I don't know how to do this in Python best, in my Ruby experience we make separate Gemfile's in subfolders and run rspec against those (example).

If this is hard to do, I would be open to merging this as is. Let's get your questions answered on the compatible versions, I think those make a lot of sense.

@iherasymenko
Copy link
Contributor Author

iherasymenko commented Apr 18, 2024

@james-certn The opensearch-py library is frequently (if not always) used together with the AWS Python SDK (https://github.com/boto/botocore/). Preferably, this library stays compatible with the Python 3.9 Lambda deployments, i.e. we don't pin the version of urllib3 to >2.x (as the urllib3 version there is pinned to 1.x) and, at the same time, we don't leave the version of urllib3 unpinned (>1.x) as it caused #628.

@dblock @saimedhi I'm thinking about adding a separate Integration Tests job that uses the public.ecr.aws/lambda/python:3.9 container so that we can make sure in a Python 3.9 environment, the right version gets picked up and this version does not conflict with the bundled boto3/botocore AWS Python SDK. Would this be a reasonable testing approach?

@dblock
Copy link
Member

dblock commented Apr 18, 2024

@dblock @saimedhi I'm thinking about adding a separate Integration Tests job that uses the public.ecr.aws/lambda/python:3.9 container so that we can make sure in a Python 3.9 environment, the right version gets picked up and this version does not conflict with the bundled boto3/botocore AWS Python SDK. Would this be a reasonable testing approach?

I would start simpler and definitely not attempt to actually make AWS calls (we want to do that, but setting up infrastructure that runs permanently is currently difficult, we need credits, etc.). Given a certain configuration (e.g. in a Pipfile), you end up with a specific version of the dependent library, hard-coded in a Python test.

@saimedhi saimedhi added 2.0 and removed 2.0 labels Apr 18, 2024
@james-certn
Copy link

I'm not sure that I've seen tests in projects for this kind of requirements configuration. Not that I'm against the idea, but it does seem (subjectively) irregular. Maybe I just don't get out enough. :)

dblock
dblock previously approved these changes Apr 22, 2024
Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

I am good with merging this (please update CHANGELOG, see below) and open an issue for tests if you aren't going to attempt it.

CHANGELOG.md Outdated
@@ -3,6 +3,7 @@ Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)

## [Unreleased]
### Added
- Added support for urllib3 2+ in Python 3.10+
Copy link
Member

Choose a reason for hiding this comment

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

Add the PR number here like the other lines, please?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

Signed-off-by: Ihor Herasymenko <ihor.herasymenko@ada.support>
@iherasymenko
Copy link
Contributor Author

@dblock Thanks. I updated the PR. I'll try to allocate some time to work on the tests this week.

Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

Let's merge since this is the same as in botocore.

@dblock dblock merged commit 54ad04d into opensearch-project:main Apr 22, 2024
54 checks passed
@iherasymenko iherasymenko deleted the urllib3-v2-support branch April 22, 2024 22:47
@james-certn
Copy link

Sorry for the Github noise, but when would a release around this be planned? Right now, the 2.5.0 versioned package as is does block a subset of users from leveraging the latest and greatest.

A ballpark of a day, a week, a month - that's all I'm asking for. ;) Thank you!

@saimedhi
Copy link
Collaborator

Sorry for the Github noise, but when would a release around this be planned? Right now, the 2.5.0 versioned package as is does block a subset of users from leveraging the latest and greatest.

A ballpark of a day, a week, a month - that's all I'm asking for. ;) Thank you!

Hello @james-certn, could you please create an issue requesting a 2.6.0 release? Similar to issues #561 and #695. Thank you!

dblock pushed a commit to dblock/opensearch-py that referenced this pull request Aug 15, 2024
Signed-off-by: Ihor Herasymenko <ihor.herasymenko@ada.support>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants