Rebase to alpine 3.19 and python 3.12

[aptalca]

Use upstream wheels instead of lsio ones
Retrieve python, pip and jemalloc versions from upstream and match
Since python is compiled from source instead of os package, we can do away with the venv. New python packages get installed in the /config folder (user home).
Due to doing away with the venv and breaking cadence with lsio wheels, package installer script also has been customized

Could use a little more testing in production before merge, but needs to be merged by April as that's when HA drops support for py 3.11
Tested update of production instance, no issues.

closes #95

When merged (or right before), the following needs done:

• Disable the HA wheelie builder (https://github.com/linuxserver/wheelie/blob/main/.github/workflows/wheelie_HA_scheduler.yml)
• Remove the org secret disabling HA external trigger

[thespad]

Have you tested upgrade scenarios with existing addon packages in /config?

[aptalca]

Existing packages in /config/lsiopy will be completely ignored, however, any package needed by HA or the custom integrations will be installed from HA wheel repo during HA start and installed to /config/.local as they did before we switched to venv.

With that said, I haven't tested it with my production install as an upgrade due to being away from home and not wanting to risk breakage :-)

[florie1706]

@aptalca As I checked my custom integrations and saw that they all should run with 3.12 I deleted the folder /config/lsiopy and restarted with your test build. Everything is up and running now. Thank you very much.

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.0-pkg-1bbf8407-dev-13ed48599dbd1f535f4f9ba4bfdfa453d2356138-pr-97/index.html
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.0-pkg-1bbf8407-dev-13ed48599dbd1f535f4f9ba4bfdfa453d2356138-pr-97/shellcheck-result.xml

Tag	Passed
amd64-2024.2.0-pkg-1bbf8407-dev-13ed48599dbd1f535f4f9ba4bfdfa453d2356138-pr-97	✅
arm64v8-2024.2.0-pkg-1bbf8407-dev-13ed48599dbd1f535f4f9ba4bfdfa453d2356138-pr-97	✅

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.0-pkg-1bbf8407-dev-9845bdb65cc47cc6befe321e7212b059be7a2a45-pr-97/index.html
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.0-pkg-1bbf8407-dev-9845bdb65cc47cc6befe321e7212b059be7a2a45-pr-97/shellcheck-result.xml

Tag	Passed
amd64-2024.2.0-pkg-1bbf8407-dev-9845bdb65cc47cc6befe321e7212b059be7a2a45-pr-97	✅
arm64v8-2024.2.0-pkg-1bbf8407-dev-9845bdb65cc47cc6befe321e7212b059be7a2a45-pr-97	✅

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.1-pkg-1bbf8407-dev-3e32d987af1fe63745df7c1e8d3eb7718f7ed800-pr-97/index.html
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.1-pkg-1bbf8407-dev-3e32d987af1fe63745df7c1e8d3eb7718f7ed800-pr-97/shellcheck-result.xml

Tag	Passed
amd64-2024.2.1-pkg-1bbf8407-dev-3e32d987af1fe63745df7c1e8d3eb7718f7ed800-pr-97	✅
arm64v8-2024.2.1-pkg-1bbf8407-dev-3e32d987af1fe63745df7c1e8d3eb7718f7ed800-pr-97	✅

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.1-pkg-12d0f3e4-dev-29f85c6ac67d815d248d5e42b26b2ab1aabd5117-pr-97/index.html
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.1-pkg-12d0f3e4-dev-29f85c6ac67d815d248d5e42b26b2ab1aabd5117-pr-97/shellcheck-result.xml

Tag	Passed
amd64-2024.2.1-pkg-12d0f3e4-dev-29f85c6ac67d815d248d5e42b26b2ab1aabd5117-pr-97	✅
arm64v8-2024.2.1-pkg-12d0f3e4-dev-29f85c6ac67d815d248d5e42b26b2ab1aabd5117-pr-97	✅

[seanosteen]

TL;DR: I've tested both AMD64 and ARM64 images based on the py312 branch, and have no issues to report. Only one suggestion for release notes at the bottom.

I've been a user of the mainstream linuxserver/homeassistant container for almost a year. Thank you for maintaining this fantastic resource!

This is my first dive into the development side of this container image. I recently forked the project and built my own arm64 and amd64 images from the py312 (https://github.com/linuxserver/docker-homeassistant/tree/py312) branch. I then tested it both as a fresh install and as an upgrade to a snapshot of my production system.

Environments Tested:
(DEV) AMD64 on Ubuntu 22.04.03 (ProxMox Guest VM) --> Docker Standalone 25.03

• Fresh install of seanosteen/homeassistant:py312 (2024.2.1) - No Issues
• Upgrade of production configuration snapshot from linuxserver/homeassistant:latest (2024.2.1) to seanosteen/homeassistant:py312 (2024.2.1) - No Issues

(PROD) ARM64 on Raspberry Pi5 --> Docker Standalone 25.03

• Fresh install of seanosteen/homeassistant:py312 (2024.2.1) - No Issues
• Upgrade of production configuration snapshot from linuxserver/homeassistant:latest (2024.2.1) to seanosteen/homeassistant:py312 (2024.2.1) - No Issues

Integrations Tested:

• Zigbee Home Automation (ZHA)

• TP-Link Smart Home

• QNAP

• Pi-hole

• MQTT

• HomeKit Device

• Google Nest

• Generic Camera

• Filesize

• Electricity Maps

• HACS Add-On and HACS-based Integrations:

  • Uptime Kuma
  • Wyze Home Assistant Integration
  • Tapo: Cameras Control
  • Govee LAN Control
  • Feedparser

One note related to switching from venv back to using /config/.local/lib/python3.12/site-packages:
Two integrations, Tapo & Wyze (both HACS) did not start on the first start-up after updating to the py312 image. The error stated that their python files were not found in /config/.local/lib/python3.12/site-packages. However, After restarting the HomeAssistant application one more time, those errors disappeared and the integrations worked as expected. I suspect that new python path variable had not propagated yet. I suggest adding a note that 2 or more restarts may be required to clear errors for integrations that install files into /config/.local/lib/python3.12/site-packages.

[aptalca]

oh wow, thanks so much for the detailed report and extensive testing.

I was able to reproduce the issue with wyze as well as simpleicons. Funny thing is, I do see that the python packages are indeed installed in the correct folder during that first start:

$ docker exec -it test ls -al /config/.local/lib/python3.12/site-packages
total 0
drwxr-xr-x 6 abc abc 108 Feb 13 18:58 .
drwxr-xr-x 3 abc abc  27 Feb 13 18:58 ..
drwxr-xr-x 3 abc abc  86 Feb 13 18:58 simpleicons
drwxr-xr-x 2 abc abc  98 Feb 13 18:58 simpleicons-7.14.0.dist-info
drwxr-xr-x 4 abc abc 196 Feb 13 18:58 wyzeapy
drwxr-xr-x 3 abc abc  99 Feb 13 18:58 wyzeapy-0.5.20.dist-info

However, HA does log the errors about missing modules and disables the integrations on that first start.

Perhaps HA's logic has changed so that it first checks for existence and decides whether to enable or not, and then installs the modules via pip whereas previously it seemed to check and install any missing manifest dependencies, and then enable the integrations on start.

In any case, this is not something in our control and is 100% controlled by upstream's init logic. It could create issues for their official image as well, if a user happens to delete the /config/.local folder. So it may actually qualify as an HA bug.

I will go ahead and add a note in the changelog.

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.1-pkg-12d0f3e4-dev-19296709b64e01a2a3ee69579a721692605f7d31-pr-97/index.html
https://ci-tests.linuxserver.io/lspipepr/homeassistant/2024.2.1-pkg-12d0f3e4-dev-19296709b64e01a2a3ee69579a721692605f7d31-pr-97/shellcheck-result.xml

Tag	Passed
amd64-2024.2.1-pkg-12d0f3e4-dev-19296709b64e01a2a3ee69579a721692605f7d31-pr-97	✅
arm64v8-2024.2.1-pkg-12d0f3e4-dev-19296709b64e01a2a3ee69579a721692605f7d31-pr-97	✅

[daxpryce]

🥳

that "YA'LL PYTHON3.11 IS DEAD IT'S DEAD YOU GOTTA UPDATE" message was giving me stupid bad anxiety, so thank you guys so much for releasing this ❤️