core: Custom integrations with requirements fail to start with 2022.7.X
The problem
I am using two integrations (hella_onyx, deebot_client) that have requirements according to their manifest.json. Since the upgrade of home assistant to 2022.7.X, both integrations fail to load:
2022-07-08 08:07:22 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration hella_onyx: Unable to import component: No module named 'onyx_client'
2022-07-08 08:07:25 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration deebot: Unable to import component: No module named 'deebot_client'
This is reopening #74597. I get that issues with custom components are not to be raised here. However, this is an infrastructure issue and not within multiple custom components using requirements in their manifest.json.
For example, installing the requirement with pip in the container (see https://github.com/py-smart-gardena/hass-gardena-smart-system/issues/125#issuecomment-1177218448) solves the problem.
However, this is not a persistent change as I’d need to run this command for every requirement of a custom component whenever my container starts or the component needs updating. Installation of requirements should be handled by the infrastructure; in this case Home Assistant Core.
Please re-investigate/reopen #74597.
What version of Home Assistant Core has the issue?
core-2022.7.1
What was the last working version of Home Assistant Core?
core-2022.6.X
What type of installation are you running?
Home Assistant Core
Integration causing the issue
all custom components with requirements
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
I suspect a regression due to the Python upgrade in how to install/handle those requirements, or probably the directory pip installs them, and Python looks for. (see https://github.com/home-assistant/core/issues/74597#issuecomment-1178562739)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 7
- Comments: 23 (7 by maintainers)
Installation method is in a Kubernetes pod/container using the
ghcr.io/home-assistant/home-assistant:2022.7.1image. There’s no custom configuration or similar around that - I take the container and run it without a mount to my configuration directory/config.Custom integrations in use are
hella_onyx, version 3.0.0, anddeebot, version 1.4.1. Both fail with the same error, and worked with2022.6.X. I added the gardena integration (version 0.2.3) which fails with above posted error.I see this line when starting home assistant which shows all enabled integrations, i believe:
The
depsdirectory in/configonly contained Python 3.9 packages as 3.10 ones are now installed to/usr/local/lib/python3.10/site-packagesnow.When enabling debug logging, I get this command to install the pip dependencies:
For reference, a simplified version (remove annotations, labels, …) of the Kubernetes Deployment is:
However, others in #74597 use podman or similar container orchestrators as well.
This project does not support that and thus is not something we consider.
Thanks, @muhlba91 for the reproduction that is helpful. 👍
@bootc Yes, that is related probably. The prefix needs to be either removed now, or, replaced by
--install-option="--prefix=".For this use case in this issue, removal should do. But it is in place folder an “older” issue with some distro. So removing it might affect users running Core on such distros.
I lean towards the latter one in that case, but not 100% sure if that works at this point (needs to be tested).
Edit to add a thought: Also, this behavior might be needed to be split more. As we might need a different behavior on Home Assistant Operating System & Supervised installs compared to the container version (They both use the same Docker image).
Awesome, thanks for the fix!
Yes, sure. That’s why I asked if support is needed here as I wasn’t aware if you looked into it already and whether just removing it is safe due to the older issue mentioned.
A fix was just merged. In general, this is an open source project. Plans are made by contributions.
I don’t think this is the place to defend or argument that. These are design decisions and limitations this project has made and documented. If you want more context, you can check out the architecture repository and the documented ADRs in that repo.
Seeing the thumbs down is OK. You don’t have to agree. I’m not saying I agree or disagree either. It’s a decision for this project on what it supports and what not.
You are free to run Home Assistant any way you like, however, unsupported/out of scope setups are in the projects scope right now.
Agree non of that is for this issue report.
Yes, I know. Maybe one day ™ Docker and containers in general should give you enough controls with with Container capabilities to have what you need without going full-root. But this a discussion for another place and time.
Same here with
containerdas runtime.Using official docker image:
Testing with linuxservers image: