Hi,
I’m playing around with Home Assistant, and one if its great features is how easy it is to extend . Just place a file in the custom_components/
folder and you’re good to go. Many examples or showcases in this forum state “put the following components in your custom_components”. And that’s great!
While this works and leads to quick results, I don’t think it’s a good way to keep custom extensions managed. There will for sure always be components that are neither mature enough nor have a large enough target audience to be included in the offical source tree. Just like “I tinkered around to get my special needs satisfied. No comments, ugly code but works. I’ll share it if someone is interested”.
I just started with HA, but knowing me and my play instinct, the custom_components
folder will for sure look cluttered in just a short amount of time. Not knowing what file originates where and what files belong together. Being a developer, this is a nightmare for me.
So here is my proposal: Let’s add support for 3rd party plugins. Directly to HA, not as a hass.io addon to target as many users as possible. The idea is to allow to specify pip packages that are resolved automatically and considered custom components. As pip also supports loading from archives, one can easily point to e.g. a github repository for this just as even stated in the dev docs.
So the configuration.yaml
would contain entries like
addons:
- name: foo
# uploaded to PyPI
install: "ha-addon-foo==1.2.3"
- name: bar
# from github
install: "https://github.com/some-user/ha-addon-bar/archive/v0.0.5.zip#ha-addon-bar==0.0.5"
# force update on start
update: true
where both addons could provide either new components or add platforms to existing ones.
And those addon
lines would exactly be would be referred to then in the forum posts. Would even support updates. And could be the entry point for an addon to become mature enough to be officially included in HA itself - or be used to allow for simple beta-testing of a new or updated component. If the whole idea got successful, one could even think about a custom addon repository.
As for the loader, I would propose to
- create an abstraction layer for component loading
- redefine the current behavior (
custom_components
andcomponents
folder) - add the
addon
functionality as separate implemention. It would use theaddons
configuration and could e.g. use custom Decorators to define Components and Platforms.
We could therefore only use the custom_components
folder as a playground. And for testing out modifications or development we could refer to outsourced packages. Even if it wasn’t for sharing, if you wanted to develop your own components, this would allow to keep them all separate in git repositories.
What do you think about this proposal?