@fabaff May I ask why you are packaging all those Home Assistant dependencies? Seems like you're taking on a huge burden by maintaining all of them?

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 110816 run on x86_64-darwin 1

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 110816 run on x86_64-linux 1

May I ask why you are packaging all those Home Assistant dependencies? Seems like you're taking on a huge burden by maintaining all of them?

I still have the romantic idea of beging able to install Home Assistant and be ready to go. No waiting till all required dependencies are installed during the first start, start again because g++ is missing and again because some devel libs are not present.

Approx. 90 % of the dependencies are very low maintenance. And the rest seems to be covered as those are broadly used Python modules. It's undeniable that at every new packages introduces possible risks and the possibility for extra work in the future.

I guess that in the meantime 50 % of Home Assistant's dependencies are present. It will not be possible to provide every dependency in the end due to licensing issues and other reasons but let's say 90 %. This would give one the option to run home automation in a very lean and highly customizable way without permanently depending on a internet uplink after the installation.

I still have the romantic idea of beging able to install Home Assistant and be ready to go. No waiting till all required dependencies are installed during the first start, start again because g++ is missing and again because some devel libs are not present.

Approx. 90 % of the dependencies are very low maintenance. And the rest seems to be covered as those are broadly used Python modules. It's undeniable that at every new packages introduces possible risks and the possibility for extra work in the future.

I guess that in the meantime 50 % of Home Assistant's dependencies are present. It will not be possible to provide every dependency in the end due to licensing issues and other reasons but let's say 90 %. This would give one the option to run home automation in a very lean and highly customizable way without permanently depending on a internet uplink after the installation.

I certainly see the benefit of that and it's why I started the Home Assistant module for NixOS a couple of years back. However, I just don't see normal Home Assistant users choosing to run it on NixOS. Those who do are enthusiasts who are able to package the dependencies they miss anyway.
The problem with Home Assistant is that the direction it's taking is orthogonal to the principles behind NixOS:

• The dynamic installation of dependencies certainly makes sense for novice users but is downright scary for anyone who is used to installing packages with a package manager. Reminds of e.g. the Dropbox client for Linux downloading a binary to $HOME/... and exec'ing that. Luckily, --skip-pip solves that issue.
• As far as I know, the NixOS module is still not able to work around the onboarding process and there is no upstream documentation of how to skip it. That means that the configuration is not actually entirely declarative.
• Configuration can in principle be done in YAML but it seems like Home Assistant is moving towards configuration from the web interface. That isn't a problem if everything can still be configured in YAML and all options are properly documented. But I'm not sure that's the case.

To be fair, I haven't had a real look at Home Assistant in a long time, so my information might be outdated.

Those who do are enthusiasts who are able to package the dependencies they miss anyway.

Indeed, but I like to think that if the dependencies are present then people can save time and not have to repeat the work. Also, some dependencies are useful if one is interested in common IoT stuff.

As far as I know, the NixOS module is still not able to work around the onboarding process and there is no upstream documentation of how to skip it. That means that the configuration is not actually entirely declarative.

The documentation is having holes. At some point in the future everything will probably be configured through the web interface and stored in .storage. My hacky way for now is to write the data in .storage right after the installation. Will not work for all situations of course.

Configuration can in principle be done in YAML but it seems like Home Assistant is moving towards configuration from the web interface.

The "move-away-from-YAML" decision makes the usage easier for the average users when discovery is helping and the platforms are popular. The downside is flexibility was lost and the mixture at the moment

To be fair, I haven't had a real look at Home Assistant in a long time, so my information might be outdated.

No, they are pretty much match with mine 😉 .