Add new service clients to the AWS SDK Python meta-package

[jonathan343]

Note

We need to implement a permanent fix for this at our infrastructure layer. I cannot prioritize that at the moment and will just manually update instead for now. Our automation does know how to bump known clients, but not add new ones.

Overview

This PR adds optional dependencies for the Connect Health, Lex Runtime V2, Polly, and Q Business clients to the aws_sdk_python meta-package.

Background

These clients are available as version 0.7.0 packages but were not installable through the meta-package’s service-specific or aggregate extras. The meta packages exposed optional dependency groups to allow for users to more easily install multiple compatible services together (e.g., aws-sdk-python[bedrock-runtime, polly].

Summary

• Add extras for:
  • connecthealth
  • lex_runtime_v2
  • polly
  • qbusiness
• Include the new extras in aws_sdk_python[all].
• Add an enhancement changelog entry.

Testing

Verified that the generated wheel metadata contains the new dependencies and correctly expands the all extra.

(aws-sdk-python) $ uv pip install -e ".[all]"
Resolved 16 packages in 1.17s
      Built aws-sdk-python @ file:///Users/gytndd/dev/GitHub/aws-sdk-python/clients/aws-sdk-python
Prepared 1 package in 130ms
Installed 16 packages in 1.71s
 + aws-sdk-bedrock-runtime==0.7.0
 + aws-sdk-connecthealth==0.7.0
 + aws-sdk-lex-runtime-v2==0.7.0
 + aws-sdk-polly==0.7.0
 + aws-sdk-python==0.7.0 (from file:///Users/gytndd/dev/GitHub/aws-sdk-python/clients/aws-sdk-python)
 + aws-sdk-qbusiness==0.7.0
 + aws-sdk-sagemaker-runtime-http2==0.7.0
 + aws-sdk-signers==0.3.0
 + aws-sdk-transcribe-streaming==0.7.0
 + awscrt==0.32.2
 + ijson==3.5.1
 + smithy-aws-core==0.7.0
 + smithy-aws-event-stream==0.3.0
 + smithy-core==0.6.0
 + smithy-http==0.4.2
 + smithy-json==0.2.3

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jonathan343]

Hmm, I'm looking at this and realizing that using == seems wrong. I don't know why we went with this instead of ~=. Using ~= seems more correct to me since it will pull the latest compatible patch versions instead of staying on x.y.0 until the next minor bump. I'll figure this out in the morning, I need to get some sleep.

[jonathan343]

I'm gonna keep this PR scoped to adding new services then follow up with the == to ~= change. Thanks for the review @Alan4506