Generally it feels like they're making deploying it as hard as possible, doing stuff like checking if supervisor is running in a docker container and just not working if it is.
This is presumably born out of frustrations with users deploying it incorrectly, but there really is no reason a supervisor based HA install can't run in a docker container. I've got a some private hacks doing just that, that I'm hesitant to post publicly in case they find some way to break it.
No idea what the obsession is with keeping a full home assistant install from running in a container, but it's very strange. Trying to add more friction so they can sell more of their dedicated hardware? Their hardware is nice and stands on it's own, the only reason I don't use it is because I want to run on an old touch screen chromebook for very low power usage.
https://wiki.debian.org/Python/HomeAssistant https://wiki.debian.org/HomeAssistant
Which is part and parcel of distro-maintainer duties - someone has to deal with the complexity, between the upstream project, linux distro or the end user.
Complaining that the upstream project won't support specific configurations or installations reads as incredibly entitled to me, especially for projects like HA or Pihole that aim to be useful to folk who may not know how to fix package dependency issues, fix a broken install, or many other such foot-guns. This would be a magnet for unpaid support.
If one is knowledgeable enough to complain about installing onto an existing install, then one is likely skilled enough to know how to side-load the app and debug and resulting challenges. It's worth noting the upstream provides the installation artifacts!
I was going to purchase a Home Assistant Yellow for my homelab, glad to know I need to minimize my interaction with the project before I pulled the trigger.
Will be sure to inform others using the project about this too, they deserve to know its a risk to rely on a project with such hostile core contributors.
Truly "Open Source" in name only (OSINO?)