Add "pyatv" Python library to Homebridge Docker image

[justjam2013]

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

[NorthernMan54]

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 ?

[justjam2013]

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.

[NorthernMan54]

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

[justjam2013]

That is awesome! Thanks for sharing, I will look at the code for that plugin. This issue can be closed then as not needed.

[justjam2013]

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.

[justjam2013]

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.

[justjam2013]

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