An ongoing theme with the developers

Posted May 24, 2025 16:23 UTC (Sat) by donbarry (guest, #10485)
Parent article: Home Assistant deprecates the "core" and "supervised" installation modes

A very unfortunate but predictable decision. The developers are indifferent to any packaging considerations other than theirs. Thus always chasing after the latest Python version, deemphasizing and in some cases removing YAML alternatives for configuration, becoming less and less an interoperable tool and more a monolithic OS of its own. Soon it'll have a mail client within.

One can certainly speculate that the trimming reflects the economic interests of the company behind it and the desire to keep the client population focused behind its offerings, rather than, say, an "apt-get install homeassistant" world.

Too many corporately-trained agile developers today have forgotten old mantras like "be liberal in what you consume and conservative in what you offer" and its related library restatement to not rely on recent library innovations when you can avoid it but do the innovation in your own product until the outside interfaces are stable and widely deployed in the libraries.

A considerate community development methodology would use conservative and stable APIs to external interfaces and be able to run on at least the current stable Debian (to use an example). But the direction from the top is pretty hostile to such suggestions. Several years ago answering their objections to providing a version of their Android remote client not dependent on Google's proprietary play services led to my being blocked from their Facebook page. (They later added this alternative after enough other protest!)

Still, it's the best alternative in this domain and I'll continue to use it, and to use it without their OS and hated containers.

An ongoing theme with the developers

Posted May 24, 2025 17:49 UTC (Sat) by smurf (subscriber, #17840) [Link] (14 responses)

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.

Difference in perspective

Posted May 24, 2025 18:17 UTC (Sat) by DemiMarie (subscriber, #164188) [Link] (7 responses)

Another perspective is that nowadays, containers and VMs have made it possible for an application to take advantage of recent versions of its dependencies, without having to worry about them being unavailable on the target platform. From that perspective, they are a huge improvement.

Difference in perspective

Posted May 24, 2025 21:02 UTC (Sat) by ballombe (subscriber, #9523) [Link] (6 responses)

No, this just create a house of card situation where bugs cannot be fixed.

Difference in perspective

Posted May 24, 2025 23:25 UTC (Sat) by jkingweb (subscriber, #113039) [Link] (5 responses)

Could you elaborate? I don't see how your statement follows.

Difference in perspective

Posted May 25, 2025 8:18 UTC (Sun) by smurf (subscriber, #17840) [Link] (4 responses)

So you have a container with a mountain of hard-coded dependencies, one of which is buggy, and all of this lives in a Docker image which you got from the net.

It's not at all easy to replace that module there. In a "real" installation you can just update the requirements file with the version# with the bugfix and restart HomeAssistant.

That being said, this is for end users. A user won't muck about with Docker images, but then they wouldn't know how to edit their Supervised installation either (not without messing it up anyway). The user files the bug, somebody else notifies upstream with a fix, and you get that in the next regular update.

Actually *running* HA in Supervised mode will continue to work because they (and we) need that mode for development and testing. It'll just not be end-user-supported by them. After all, you can't rebuild a Docker image or re-provide+-boot your appliance every time you fix a typo, that'd take much too long.

Difference in perspective

Posted May 25, 2025 9:49 UTC (Sun) by ballombe (subscriber, #9523) [Link]

And in addition , this encourages supporting only the latest version of the dependencies instead of the most tested and most reliable. So anybody whose system is slightly different from upstream CI will hit bugs that upstream will flag as
"nonreproducible".

Difference in perspective

Posted May 25, 2025 11:36 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> After all, you can't rebuild a Docker image or re-provide+-boot your appliance every time you fix a typo, that'd take much too long.

On the contrary, it's increasingly common these days that the only build artifact produced is a docker image.

Difference in perspective

Posted May 25, 2025 18:52 UTC (Sun) by smurf (subscriber, #17840) [Link]

Python is a script language. No sane developer is going to wait for a Docker build on every edit-test-debug cycle.

Difference in perspective

Posted May 25, 2025 18:56 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> Actually *running* HA in Supervised mode will continue to work because they (and we) need that mode for development and testing. It'll just not be end-user-supported by them. After all, you can't rebuild a Docker image or re-provide+-boot your appliance every time you fix a typo, that'd take much too long.

The way the HA environment is set up, you can create "patches" in the `config/custom_components` folder, the Python file loader looks there first. So you can replicate the directory structure of the affected package and patch individual files. Once you're done, you can do a full-blown build.

And even for the core development, you don't need the full Supervised mode. Just clone the repo and install dependencies for the core and the parts that you want to change.