Core: Build dependencies in setup.py

[NicoHood]

Hi,
I try to build home assistant for ArchLinux. I am currently improving the AUR package and thinking of moving it to the official [community] repository.

Currently we need to patch setup.py, because our python dependencies have never versions than the one required by home assistant. Since they are backwards compatible most of the time, it should just work as expected.

So could you please list the deps as >= rather than ==?

As another requirement for publishing home assistant all deps and home assistant itself needs to be gpg signed. #9487 I hope to get some positive feedback from your side.

[tgurr]

I just want to add myself to that request packaging Home Assistant for the Exherbo Linux distribution (see https://git.exherbo.org/net.git/tree/packages/net/homeassistant/)
as I also have to patch/sed setup.py and the various python scripts where the dependencies are specified as ==. It might be fine for hass/hassbian/hass.io itself to rely on static versions where the installation is more or less isolated, but for distributions wanting to properly package Home Assistant it's an absolute no-go where alternatives like openHAB currently definitly have their advantages over Home Assistant.

[fabaff]

Since they are backwards compatible most of the time

"most of the time" is the key here. The version pinning is there to avoid issues as the backwards compatibility is not guaranteed. aiohttp, colorlog, multidict, keyring, and chardet (just to name a few) introduced breaking changes in the past which has led to unusable installations.

A current example: dev-python/colorlog[>=3.0.1][python_abis:*(-)?] will install colorlog-3.1.0 on Exherbo. There will be an issue because parse_colors was removed but we are still using it.

For Fedora and Alpine Linux we were thinking about delegating the installation of dependencies to the system's package management system. This effort was stopped because it would require that all of Home Assistant's dependencies are available out of the package repositories instead of PyPI.

The start of mixing the source of packages in site-packages is in most cases also the beginning of side effects which are hard to track and the frustration of users. Providing a subset of the requirements and not only core ones will make it worse as you will pull in dependencies and perhaps overwrite a Python module which was previously installed with the distributions's package management tool. Now there is a newer version available on the system but the local package DB was not updated.

We are all ears for a proper solution. I guess that we are looking at 300 possible requirements and an unknown number of dependencies. To ensure a minimal quality standard we test every module update manually (if possible). With == we can say that the component/platform will work. As far I can tell is requests the only requirement which is not pointing to the latest release in setup.py. A quick check with multiple of our requirements about the availability on Exherbo and ArchLinux showed that they will come out of PyPI anyway as they are not packaged so it doesn't make sense to go with >= for the components and platforms.

[tgurr]

A quick check with multiple of our requirements about the availability on Exherbo and ArchLinux showed that they will come out of PyPI anyway as they are not packaged so it doesn't make sense to go with >= for the components and platforms.

I'm still in the proccess of packaging required dependencies, however at least for Exherbo the userbase is quite small and I tend to only add/package things I can either test myself or get reports/requests for.

The start of mixing the source of packages in site-packages is in most cases also the beginning of side effects which are hard to track and the frustration of users.

To not run into such a situation you've mentioned with having mixed installations for packages outside the package managers control we pass --skip-pip in the systemd service unit for Home Assistant, keeping things clean and easier for us to manage without creating a huge mess. And it hopefully also prevents users from complaining to you if something is missing/doesn't work on Exherbo in the first place. (Thanks at this point for providing an easy way to at least have an option to disable automatic installations of packages, this is a huge help for us!)

We are all ears for a proper solution.

For the rest I'm probably not a big help, if I would have a sensible idea on how to make everyone happy I probably would've created such a request as well when I started packaging Home Assistant for Exherbo nearly a year ago. So whoever might come up with something that makes the life easier for downstream packaging he/she will have my thanks for sure.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[kamaradclimber]

This is still an issue at the moment, dont close it yet

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[NicoHood]

Still valid.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[FedericoCeratto]

Still valid. This is preventing Home Assistant from being packaged.

[awarecan]

I don't think we need keep this open. HA is not designed to be packaged in Linux. Feel free to open a new architecture issue if you have a solution to propose.

I am going to close it.