[BUG] ModuleNotFoundError: No module named 'orjson.orjson'

[Ulrar]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

HA 2024.12 fails to start, crashing.

It seeme to be missing a dependency, most likely related to the python 3.13 upgrade. It looks like it's trying to use python 3.12 as well, although that may be hacs related I suppose.
Will revert back to 2024.11 for now.

Expected Behavior

No response

Steps To Reproduce

Use the latest image

Environment

- OS: Talos
- How docker service was installed: Kubernetes

CPU architecture

x86-64

Docker creation

N/A

Container logs

Failed to set capabilities on file '/usr/local/bin/python3.12': No such file or directory
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/local/lib/python3.13/site-packages/homeassistant/__main__.py", line 227, in <module>
    sys.exit(main())
             ~~~~^^
  File "/usr/local/lib/python3.13/site-packages/homeassistant/__main__.py", line 174, in main
    args = get_arguments()
  File "/usr/local/lib/python3.13/site-packages/homeassistant/__main__.py", line 84, in get_arguments
    from . import config as config_util
  File "/usr/local/lib/python3.13/site-packages/homeassistant/config.py", line 27, in <module>
    from .core import DOMAIN as HOMEASSISTANT_DOMAIN, HomeAssistant, callback
  File "/usr/local/lib/python3.13/site-packages/homeassistant/core.py", line 93, in <module>
    from .helpers.json import json_bytes, json_fragment
  File "/usr/local/lib/python3.13/site-packages/homeassistant/helpers/json.py", line 12, in <module>
    import orjson
  File "/config/deps/orjson/__init__.py", line 3, in <module>
    from .orjson import *
ModuleNotFoundError: No module named 'orjson.orjson'

[github-actions]

A human has marked this issue as invalid, this likely happened because the issue template was not used in the creation of the issue.

[Ulrar]

It took quite a bit of fiddling, but I got it to work now.
For reference in case anyone else ends up here, here is what I think solved it :

First, remove the existing deps directory. This allows home assistant 2024.12 to start again :

rm -Rf /config/deps

At this point HA starts, but all the integration that depend on uv installing packages are broken.

uv pip install pymyenergi --index-strategy unsafe-first-match --upgrade --constraint ./usr/local/lib/python3.13/site-packages/homeassistant/package_constraints.txt

Restart, and HA won't start again because a very old asyncio got installed by the above.

rm -Rf /config/deps/asyncio*

Restart once more, and everything is fixed. I had four broken integration, and manually re-installing one of their deps fixed all of them, somehow. Then just delete asyncio, not sure how that one gets installed with the constraints but it works.

It's worth noting I'm using the env fix for uv as well : PYTHONPATH: /config/deps. I wondered if maybe the issue was they finally fixed this in the new version but no, this is still needed for external packages to get found, I tried removing it and re-installing everything to no avail.

Anyway, hopefully this helps if anyone else runs into the same issue.

[aptalca]

It's worth noting I'm using the env fix for uv as well : PYTHONPATH: /config/deps

That's likely why you're having the issue in the original post and that's why this issue is marked as invalid (you didn't include your docker run or compose so we had no idea what you did and no way we can reproduce).

Runtime uv install was fixed shortly after it was introduced.

We don't support your method of changing python path and manual uv install.

[Ulrar]

I don't have a docker command, as I'm using kubernetes. I can include my statefulset definition, if that helps.

Runtime uv install was fixed shortly after it was introduced.

We don't support your method of changing python path and manual uv install.

It's a different problem. That env var is needed because of an issue in core, as I understand it. See the details here : home-assistant/core#127966 (comment)

Without that env var, the integrations that depend on uv install can't find their dep (as it gets installed in a dir that they don't load from) and can't load. That thread mentions another workaround (creating /.dockerenv) but I haven't tried that.

[rsteckler]

Same issue here. I'm guessing more people will be along shortly. To recap:

1. HA broke dynamic library installations for docker containers (Integrations that require a Python module installation fail to add on 2024.10.1 when installed through HACS home-assistant/core#127966)
2. A bunch of us used the workaround (Integrations that require a Python module installation fail to add on 2024.10.1 when installed through HACS home-assistant/core#127966 (comment))
3. Now the docker HA container broke the workaround and the original issue is still broken, so we're now looking for another workaround until HA-core gets fixed.

[rsteckler]

Without that env var, the integrations that depend on uv install can't find their dep (as it gets installed in a dir that they don't load from) and can't load. That thread mentions another workaround (creating /.dockerenv) but I haven't tried that.

Just confirming that adding .dockerenv works. I removed the pythonpath workaround, restarted the docker container, and saw my integrations failing to load again.
Then I shelled into the container and ran touch /.dockerenv and restarted HA (but NOT the container) and it came back online with all of the integrations.
Of course, as soon as the container restarts I'll need to login again and re-create the file, but this seems to be working at the moment.

[Ulrar]

If that works just mount it as a volume, so the file exists on startup.

But someone said with that file it starts but re-installs the libs on each start, is that the case ?
I really don't want to depend on the internet to start HA, so I like having the libs in /config myself

[aptalca]

I am not aware of any issues currently with HACS in our image. When HA first switched to uv from pip, our image did have issues, but were all fixed: #111 #109 #107

If you're having issues, please open a new issue and provide all the details. But keep in mind that the official image and ours are quite different so just because an issue happens on the official, it doesn't mean it happens here. In other words, I'm not interested in issue reports about the official image and I'm also not interested (at this point) about any workarounds you may be using. I need to be able to see and reproduce the raw issue in our image without any attempted workarounds.

[Ulrar]

If anyone is following this here but not the issue on the core side, someone came up with an IMHO better solution to work around this in this comment.

Here's my modified version for the linuxserver image, in case anyone else wants to go that route :

    #!/usr/bin/with-contenv bash
    # shellcheck shell=bash

    PY_LOCAL_PATH=$(find /usr/local/lib -maxdepth 1 -name python* -type d)
    PY_LOCAL_BIN=$(basename "${PY_LOCAL_PATH}")
    setcap 'cap_net_bind_service=+ep' "/usr/local/bin/${PY_LOCAL_BIN}"

    if [[ -z "${DISABLE_JEMALLOC+x}" ]]; then
      export LD_PRELOAD="/usr/local/lib/libjemalloc.so.2"
      export MALLOC_CONF="background_thread:true,metadata_thp:auto,dirty_decay_ms:20000,muzzy_decay_ms:20000"
    fi

    pyenv_hash=$(uv pip list | sha256sum | cut -d " " -f 1 )
    arch=$(uname -m)
    venv_path="/config/venv/$pyenv_hash/$arch"
    unset UV_SYSTEM_PYTHON
    mkdir -p /config/venv/
    uv venv --system-site-packages --link-mode=symlink --prompt "${pyenv_hash:0:8}-$arch" $venv_path
    ln -fs $venv_path /config/venv/current_venv
    source /config/venv/current_venv/bin/activate
    uv pip freeze --system | grep ^uv= | xargs uv pip install
    echo $arch > /config/venv/LASTARCH
    echo $pyenv_hash > /config/venv/LAST_PYENV_HASH
    chown abc:abc -R "${venv_path}"

    exec \
        s6-notifyoncheck -d -n 60 -w 5000 -c "nc -z localhost 8123" \
        s6-setuidgid abc python3 -m homeassistant -c /config

Just mount this over /etc/s6-overlay/s6-rc.d/svc-homeassistant/run and you're set. Will add an extra check in there to delete older folders at some point.

For kubernetes, I put that file in a configmap and configured it as a volume mount over that file, works great.

This should have the advantage of not being finicky during HA upgrades (with dep version changes) like the PYTHONPATH var entails, while not requiring the internet on every pod restart (as intended by the core HA team).