Constrain uamqp for Python 3.10 only

[frenck]

Proposed change

This PR adds back the constraint to uamqp, but this time for Python 3.10 only.

It is a really odd move to make. Reason: We need to release this constrain to get our Python 3.11 development going in #88038.

The problem is we can't build the wheels for the most recent versions against armhf & armv7 (32-bit arm). The upstream project also doesn't provide wheels for it.

At this point, we don't ship our images with Python 3.11 yet (which will take a bit still), so using this constrain, we can still continue our Python 3.11 development and testing, while maintaining our current Python 3.10 releases working.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[frenck]

@eavanvalkenburg Do you happen to know if there is ETA on the pure Python implementation? That would solve this problem for us completely. Right now, it is pretty blocking in the short-term for us.

../Frenck

[eavanvalkenburg]

Just asked, in beta soon, but they do have wheels for 3.10 and 3.11

[bdraco]

Tested: Seems to work as expected 👍

[frenck]

Just asked, in beta soon, but they do have wheels for 3.10 and 3.11

@eavanvalkenburg They don't have wheels for musllinux (which we use), nor do they provide wheels for arm 32 bits (armhf/armv7) (architectures which we use).

But good news something is coming 👍

[eavanvalkenburg]

Indeed not for all platforms, if you want early beta access to validate sooner let me know!

[frenck]

Validation is not our issue perse, it is mostly being able to publish for / move forward with the arm32 architectures (and being able to publish/support Python 3.11 eventually).

[kashifkhan]

Hi @frenck, I'm on the python messaging SDK team and we have a beta coming out soon (its going through review). We do have an alpha out there as well published and would love to have yall on the beta (if not alpha), especially as it removes a big blocker.

Looking at the component using service bus since its sending notifications to service bus, without using some of the other logic its a relatively safe move. Its also designed to be just like the event hub SDK with the move being seamless and not having to build uamqp for ARM etc.

[frenck]

I think, if there is a public beta @kashifkhan (as in, a package published on PyPi), we could consider joining that. That said, we generally don't use non-stable releases.