Relax botocore dependency specification

[jakob-keller]

Description of Change

This PR intends to improve general compatibility of aiobotocore within the Python ecosystem by relaxing the dependency specification of botocore.

Assumptions

Upstream contains no changes that require adjustments to the aiobotocore codebase.

Checklist for All Submissions

• I have added change info to CHANGES.rst
• If this is resolving an issue (needed so future developers can determine if change is still necessary and under what conditions) (can be provided via link to issue with these details):
  • Detailed description of issue
  • Alternative methods considered (if any)
  • How issue is being resolved
  • How issue can be reproduced
• If this is providing a new feature (can be provided via link to issue with these details):
  • Detailed description of new feature
  • Why needed
  • Alternatives methods considered (if any)

Checklist when updating botocore and/or aiohttp versions

• I have read and followed CONTRIBUTING.rst
• I have updated test_patches.py where/if appropriate (also check if no changes necessary)
• I have added URL to diff: boto/botocore@1.42.42...1.42.49

[gemini-code-assist]

Important

Installation incomplete: to start using Gemini Code Assist, please ask the organization owner(s) to visit the Gemini Code Assist Admin Console and sign the Terms of Services.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.60%. Comparing base (b28882c) to head (b821f1d).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1474   +/-   ##
=======================================
  Coverage   91.60%   91.60%           
=======================================
  Files          76       76           
  Lines        8078     8078           
=======================================
  Hits         7400     7400           
  Misses        678      678           

Flag	Coverage Δ
no-httpx	88.46% <ø> (ø)
os-ubuntu-24.04	91.60% <ø> (ø)
os-ubuntu-24.04-arm	89.61% <ø> (ø)
python-3.10	89.57% <ø> (ø)
python-3.11	89.57% <ø> (ø)
python-3.12	89.57% <ø> (ø)
python-3.13	89.57% <ø> (ø)
python-3.14	91.56% <ø> (ø)
python-3.9	89.58% <ø> (ø)
unittests	91.60% <ø> (ø)
with-awscrt	91.23% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[webknjaz]

In pip-tools, we're talking about having an extra with an upper bound for the dep we're actually testing. In general, upper boundaries in mandatory metadata is considered harmful (with my PyPA hat on) and such bumps create a lot of noise too causing too much burden (with my serial maintainer hat). For this reason, I tend to configure dep bumping automations (dependabot, pre-commit.ci etc) to be as unfrequent as possible, short of security fixes, of course.

Having to approve this many seemingly pointless bumps every day just steals time from more urgent/useful maintenance needs. I'm approving this but I'll probably change the branch protection to allow self-approvals to try to reduce this burden. Though the correct fix is not having the upper bounds in this place of the metadata.

[jakob-keller]

Having to approve this many seemingly pointless bumps every day just steals time from more urgent/useful maintenance needs. I'm approving this but I'll probably change the branch protection to allow self-approvals to try to reduce this burden.

Makes a lot of sense to me.

Though the correct fix is not having the upper bounds in this place of the metadata.

aiobotocore by design relies on patching of private botocore code. As a result, each botocore patch release is potentially breaking for us and our users. IMO, this justifies the tight upper bound on botocore, allowing relaxation only after successfully reviewing and testing each subsequent botocore release.

[webknjaz]

aiobotocore by design relies on patching of private botocore code. As a result, each botocore patch release is potentially breaking for us and our users.

pip-tools has exactly the same use case. And so we want to let the end-users opt in through an extra but not create busywork. What they need for reproducibility is lock files and testing when they are regenerated.

[jakob-keller]

pip-tools has exactly the same use case. And so we want to let the end-users opt in through an extra but not create busywork. What they need for reproducibility is lock files and testing when they are regenerated.

Opened #1475 to pick up your suggestion and continue discussion.