An ongoing theme with the developers

Posted May 24, 2025 17:49 UTC (Sat) by smurf (subscriber, #17840)
In reply to: An ongoing theme with the developers by donbarry
Parent article: Home Assistant deprecates the "core" and "supervised" installation modes

Yes, it'd be nice if somebody would do the work to make "apt-get homeassistant" happen. Shouldn't be too much work, to be honest, as the first step (after adding a HASS user) is to create a Python virtualenv. The biggest problem is that it's going to be a year or two out of date on your stable distro. (Unless step two is to download the current version and then auto-update it. At that point you don't need apt-get any more: you just want a comprehensive installation script.)

It'd be even nicer if that could work without a venv, but there are far too many supported integrations for that to happen, given that each one needs its own Python package (with wildly varying actual version specificity) *and* basically no automated PyPI import to Debian.

An ongoing theme with the developers

Posted May 25, 2025 13:25 UTC (Sun) by philh (subscriber, #14797) [Link] (12 responses)

> Yes, it'd be nice if somebody would do the work to make "apt-get homeassistant" happen. Shouldn't be too much work ...

See: https://wiki.debian.org/Python/HomeAssistant

That page states that there were 675 missing python packages required when they started the recent push to package Home Assistant. The aim there was to finish packaging it this year, and they seem to have already done well over 400, so I guess strictly speaking it looks like it will not in fact be "too much" effort in the end ;-)

Hopefully that will then give people a place to gather in order to be able to maintain an installable version.

Regarding the out-of date aspect of packaging such a thing, one could maintain a fresh version in `fasttrack.debian.net`, but personally I'd trade something that had proven reliable over a couple of years for whatever this week's latest feature is when it comes to controlling my home when I'm not in the building.

An ongoing theme with the developers

Posted May 27, 2025 17:48 UTC (Tue) by Sesse (subscriber, #53779) [Link] (1 responses)

I find it amusing that anything that depends on 600+ Python packages and wants 2GB+ RAM “for a basic setup” describes itself as “very lean”. I mean, what stuff exists in this space that has higher requirements?

An ongoing theme with the developers

Posted May 27, 2025 18:09 UTC (Tue) by smurf (subscriber, #17840) [Link]

It depends on 600 Python packages only if you activate each and every one of the gazillion integrations that come with Home Assistant. Fortunately the typical home uses far fewer than 100 different kinds of device.

The reason you want more than enough RAM isn't that you can't set up a usable system with less, one of my test systems runs perfectly well in a 400MB VM. The reason is that if there's even a hint of memory pressure, the system might need to swap something in when you hit a light switch. Few things in a home automation setup are more annoying to the users, esp. the not-computer-savvy ones, than random delays.

An ongoing theme with the developers

Posted May 27, 2025 20:36 UTC (Tue) by jdulaney (subscriber, #83672) [Link] (5 responses)

Needing 600 dependencies just means you don't know how to code.

An ongoing theme with the developers

Posted May 27, 2025 20:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Real coders have 6000 dependencies!

The HA has a rule that integrations should not have any device interaction logic inside them, they should farm it out to a library. That's where most of 600 dependencies come from.

This makes it easier to develop device integrations, and forces a clean separation between device handlers and HA core logic.

An ongoing theme with the developers

Posted May 28, 2025 8:00 UTC (Wed) by taladar (subscriber, #68407) [Link]

Counterpoint, having only a few dependencies in a large project means your language makes it unreasonably hard to start a new library so you end up with kitchen sink dependencies like Qt instead of the many independent ones you get in a language with better tooling.

An ongoing theme with the developers

Posted May 28, 2025 8:17 UTC (Wed) by smurf (subscriber, #17840) [Link] (2 responses)

Not in this case.

Those 600 deps mean that HA uses existing and hopefully-tested-on-actual-hardware Python libraries to talk to $THING, which can be stubbed out for unit testing rather easily, instead of re-inventing 200 wheels that can't be tested without the actual hardware.

An ongoing theme with the developers

Posted May 28, 2025 9:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

> which can be stubbed out for unit testing rather easily, instead of re-inventing 200 wheels that can't be tested without the actual hardware.

And with hardware, you can test it directly instead of needing an HA installation to drive it.

An ongoing theme with the developers

Posted May 28, 2025 19:13 UTC (Wed) by smurf (subscriber, #17840) [Link]

… and without hardware *and* without an abstraction layer, you can't test anything and are SOL.

You get to guess how many CI runners, or users for that matter, have 100 different kinds of home automation hardware attached to them.

An ongoing theme with the developers

Posted May 29, 2025 10:43 UTC (Thu) by Rigrig (subscriber, #105346) [Link]

> I'd trade something that had proven reliable over a couple of years for whatever this week's latest feature is

Unfortunately "this week's latest feature" is often "talking to devices with this week's firmware update". Even if the manufacturer is decent enough to give you the choice, that still means choosing between "works with x-year old Home Assistant" and "latest (security) fixes".

An ongoing theme with the developers

Posted May 29, 2025 20:06 UTC (Thu) by zigo (subscriber, #96142) [Link] (2 responses)

Hi,

I'm one of the 2 crazy guys that started this effort. Packaging all of these libraries, I found out that some are very well maintained, contain unit and functional tests, and some are really bad, with only a few lines of Python. So quality varies a lot.

What is pushing me to do this packaging work, is mostly because I kind of hate the way HomeAssistant is delivered by upstream. I also hate that it's updating every odd days: I don't need that, I want my home automation to be STABLE. In the sense: I don't want it to be a constantly moving target. I don't need new features more often than Debian Stable (ie: once every 2 years is really enough). I also hate having 100s of containers, and having a very poor access to it. I prefer all of these python things to be installed flat out, on my system, together with other things. I also don't want a specialized VM (which is what I'm currently using because ... no other viable choice), and I would like to be able to install other things in my home server than just HomeAssistant. I don't want also HomeAssistant to use the root of my home web server, or to use a specialized port, I would like it to just share port 443, like every other app in Debian, and just use /homeassistant (or /ha ?), and leave the rest of the namespace for *ME* to decide what to host in my web server/haproxy/whatever. Simple things like having SSL support in HA is just horrible. :(

So far, it takes us (me and the other DD) about 15 to 20 minutes to package a Python library, thanks to highly automated tooling.

I have to admit that I did a lot from July to October, and then did other stuff. I intend to restart the effort this summer, hopefully a bit during Debconf in July. However, help would be highly appreciated. If we get 20 people doing 10 package each, we're done! Having to finish the 200+ packages with only 2 persons WILL take a lot of time. Then once we're done, the fun part begins: we'll start playing the the core stuff, it's going to be fun.

Hopefully, we can have something that works well enough for Debian 14 (aka: Forky). Also hopefully: it's going to be practical in Debian Testing before then.

An ongoing theme with the developers

Posted May 29, 2025 22:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> I don't want also HomeAssistant to use the root of my home web server, or to use a specialized port, I would like it to just share port 443, like every other app in Debian, and just use /homeassistant (or /ha ?), and leave the rest of the namespace for *ME* to decide what to host in my web server/haproxy/whatever. Simple things like having SSL support in HA is just horrible. :(

You can do that just fine with HA and containers. Have the HA run on a port like 8080, and set up your frontend webserver/proxy to redirect everything for the '/ha/*' path to that port.

HA itself works fine with URLs that are not rooted, I believe you just need to set the `external_url` property in the YAML config for that.

An ongoing theme with the developers

Posted May 30, 2025 6:43 UTC (Fri) by smurf (subscriber, #17840) [Link]

> I prefer all of these python things to be installed flat out, on my system, together with other things.

Amen, brother.

> I also don't want a specialized VM (which is what I'm currently using because ... no other viable choice),

I'm using a simple venv, and a startup script that activates it and then starts the HA that's been pip-install'd into it. Works perfectly fine. So I wonder what do you need the VM for?

An ongoing theme with the developers

Posted Aug 9, 2025 22:51 UTC (Sat) by Rudd-O (guest, #61155) [Link]

HA won't be happening as a traditional system-wide apt-get or dnf install, because HA insists on installing various versions of various packages in its own very much owned env. Those packages are only installed at runtime when an integration is added by the user.