docker-homebridge
docker-homebridge copied to clipboard
homebridge
Add "pyatv" Python library to Homebridge Docker image
Current Situation
Plugins that use the Python pyatv/atvremote package to provide AirPlay require connecting to the Homebridge Docker container and performing a manual install of pyatv, as Homebridge does not install it as part of the plugin. This process has to happen every time the user updates to a new the Docker image, or recreates the container.
Proposed Change
Currently Homebridge UI shows if Homebridge, Homebridge UI, or plugins have updates. As pyatv is installed manually, there are no notifications if a new version with fixes or enhancements becomes available.
As AirPlay is a standard service in the Apple ecosystem (not HomeKit), it would be convenient if it came preinstalled by default in the docker image.
By adding one line to the Homebridge Dockerfile:
RUN pip3 install pyatv
the latest version of pyatv would become available when the Docker image is updated.
Additional Context
No response
Python is included as part of the homebridge-apt-pkg here - https://github.com/homebridge/homebridge-apt-pkg/blob/latest/deb/debian/control
Maybe we should reinstall the apt-pkg ?
Yes, python is available and pip, which makes things a lot easier. My suggestion was including pyatv, as plugins that provide AirPlay capabilities use it. Well ... two that I have come across!
I do understand that this would not be standard fare, and is just for the benefit of AirPlay plugins.
My suggestion is simply because it's a small change in the Dockerfile, but would simplify the process for non-tech savvy users.
The python environment is in support of this plugin - https://github.com/maxileith/homebridge-appletv-enhanced
And it does not need pyatv installed, it is installed as part of the plugin installation process
That is awesome! Thanks for sharing, I will look at the code for that plugin. This issue can be closed then as not needed.
Reopening this enhancement suggestion because every time the docker container is recreated (new image or changes to docker-config.yml), pyatv needs to be reinstalled again. Until atvremote is available, the plugin is non-functional.
I am running Homebridge inside Docker on a Raspberry Pi 4B, with 4GB of memory, and it takes quite awhile to install pyatv inside the container*. The steps taking the longest are building the wheels for miniaudio and zeroconf each time, with the zeroconf wheel taking a long time. Note: I have not timed the install, but it does take a long time ... "guesstimating" 5-10 minutes.
I reviewed homebridge-appletv-enhanced and it builds a virtualenv on the host and then attaches the .venv folder as a docker volume. This allows the python installed packages to survive recreating containers.
While this makes sense for this plugin, as it installs ~30 python dependencies into the virtual env, this is a heavy handed solution for a single Python package.
There is no way of sharing from the host just the /usr/local/bin/atvremote executable with a docker container, /usr/local/bin/ cannot be attached to the container as it will then overwrite the docker container folder, and if you share atvremote in another directory, then you have to still enter the container to make sure that this folder is on the path.
Whereas installing pyatv by default in the Homebridge Docker image would be a one-line change to the Dockerfile.
As mentioned, I understand that AirPlay is not part of HomeKit, but I hope that this enhancement suggestion will be considered, as AirPlay is a standard service in the Apple ecosystem.
There is no way to programmatically modify a container after creation. You have to manually attach to it and manually install any additional dependencies.
I explored, extending the Homebridge Docker image and creating a new Docker file:
FROM homebridge/homebridge
pip3 install pyatv
but that is even more heavy handed. It programmatically adds the python dependency, but it also rebuilds the docker image each time, making startup time even longer.
Additional comment: homebridge-appletv-enhanced is only supported on Linux, it is not supported on other platforms. It may run in MacOS, but the plugin author specifically says that
"it should run on MacOS just fine".
Other OSes are not supported because both miniconf and zeroconf either contain platform-dependent code or have platform-dependent dependencies, so sharing a cross OS executable will not work.
During the build process, I am seeing the following entries specifically call for a platform-dependent wheel:
aiohttp-3.10.10-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
protobuf-5.28.2-cp38-abi3-manylinux2014_aarch64.whl
cryptography-43.0.3-cp39-abi3-manylinux_2_28_aarch64.whl
yarl-1.15.5-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
multidict-6.1.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
frozenlist-1.4.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
cffi-1.17.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
pydantic_core-2.23.4-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
charset_normalizer-3.4.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
propcache-0.2.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
and finally the wheel created are platform dependent themselves:
Created wheel for miniaudio: filename=miniaudio-1.61-cp310-cp310-linux_aarch64.whl
Created wheel for zeroconf: filename=zeroconf-0.135.0-cp310-cp310-manylinux_2_35_aarch64.whl
Update
Adding this for completeness on this issue.
In Sessings, under Startup & Environment, there is the menu entry Startup Script. The description says This script will be executed each time the docker container starts. You can use this to install any extra packages your plugins may need such as ffmpeg or libpcap-dev. So this could be used to automate the installation. When the docker container is started, it will install pyatv, if it isn't installed already.
It still doesn't take away the time it takes to build the platform dependent wheels, but it does automate the installation process each time a new docker container is created. And it does remove the slippery slope of "it's just one package", slowly leading to creep and bloat.
If there is no appetite to add pyatv to the Docker image, this is an acceptable solution and this ticket can be closed.
Waiting on this issue: Missing 'Startup Script' option in Settings on MacOS If the 'Startup Script' option is only available on Linux then it's a not a workaround solution for non-Linux OSes.
I just got a reply on the ticket I opened for homebridge-ui-x: Missing 'Startup Script' option in Settings on MacOS While it doesn't remove the issue with long build time for the dependencies, it does resolve the issue of having to manually reinstall requirements every time the container is recreated. Not the perfect solution, but perfectly functional.