Bump numpy to v1.22.3

[epenet]

Proposed change

https://github.com/numpy/numpy/releases/tag/v1.22.3
https://github.com/numpy/numpy/releases/tag/v1.22.2
https://github.com/numpy/numpy/releases/tag/v1.22.1
https://github.com/numpy/numpy/releases/tag/v1.22.0

numpy/numpy@v1.22.3...v1.21.6

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)
• 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: RuntimeError: module compiled against API version 0xf but this version of numpy is 0xe #71270
• 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.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

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

[probot-home-assistant]

Hey there @bachya, mind taking a look at this pull request as it has been labeled with an integration (iqvia) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[probot-home-assistant]

Hey there @Petro31, mind taking a look at this pull request as it has been labeled with an integration (compensation) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[epenet]

⚠️ v1.22.3 does not have a wheel build on the wheels repo (yet?).

[epenet]

⚠️ v1.22.3 does not have a wheel build on the wheels repo (yet?).

It seems that wheels get built on merge to master. I don't know if there is a way to force a wheels build to be able to test on a failing instance?

[thecode]

So looking at numpy source code it has the following C_API_VERSION by numpy release:
https://github.com/numpy/numpy/blob/ba54f569cecf17812695f17812d238af2bb91000/numpy/core/setup_common.py#L45-L49

# 0x0000000e - 1.20.x
# 0x0000000e - 1.21.x
# 0x0000000f - 1.22.x
C_API_VERSION = 0x0000000f

We already compile our wheels with version 0xf which explains why any 1.21.x version won't work.
I think it should be safe to merge this PR and build the wheels again.

[pvizeli]

The issue is, the last time we tried to update to 1.22.x (it was 1.22.0), the i386 platform did not work. So before we can merge this, we need to be sure that it was fixed; otherwise, we have to define first a process on how we can take device support down. That could be quite a complex process.

Future, we should make sure we use on our org the same version to avoid this. The simplest would be to which library was built against the wrong number. So maybe we have to freeze NumPy hard on our build system and rebuild everything new.

I will test this on Monday to see if our i386 platform now work with this numpy version

EDIT:
#63648

EDIT:
It seems alpine was able to build that with 1.22.3 on edge: https://pkgs.alpinelinux.org/package/edge/community/x86/py3-numpy but we should test it before anyway. At least first on dev

[pvizeli]

We can attach the milestone, once it worked and was not needed to revert

[pvizeli]

I guess it's only a 3party wheel that affect the issue: