Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Embedded platforms and the road to packaged components #124
So @rytilahti had a good point in his long (and mainly off-topic
@rytilahti proposed to make each platform a folder with their own metadata file. I've always shot this idea down, because it means that all our code has to be written twice, once for things based as a component and once for things based as a platform. That would be a maintenance hell and thus hinder progress.
However, thinking about this, I realized that we can embed the platforms in components. That way we forget about the idea of "platforms" altogether. Instead, an entity component can load embedded platforms from other components.
File structure wise, we would go from:
The content of the file stays exactly the same, but now we have all code for a single component in one folder.
This means a bunch of things, among others:
The only one I can think of is that once all built-in platforms are embedded and we deprecate the old pattern of
referenced this issue
Dec 20, 2018
IMO this is a slam dunk.
Should we also consider separating entity components, and integration components? I think that if we get rid of the notion of having entity platforms hosted underneath our base components, it makes sense to separate those from our integrations, since those are more of a core concern.
To limit issues with circular dependencies the init.py must be mostly empty. Since importing component/x/const.py will automatically load init.py. thus we don't want that to pull in a bunch of stuff.
PS. Im from the referenced wip branch above where I ran into problems with the constants for climate being defined inside climate platform, but needed from helpers.
This will be lovely for custom components too btw. Since it allow:
Ie multiple custom components hosted by somebody else. Now it's messy since they need to populate same directories.
Edit: Realised it was already mentioned.
What are the remaining points that are to be discussed under this issue, assuming we are agreeing that the proposal sounds good enough to start tinkering with the code? I suppose the only (sofar) listed downside is not a major issue.
Should a new issue discussing the implementation be opened? The remark from @petri would be on-topic there (and IMO that is the way to go for the implementation, making (custom) components pypi installable is a nice side-effect of using an existing 'metadata' possibilities of setuptools).
You can open an issue and discuss MVP, only represent functionality we have today in a manifest. Discovery is beyond MVP, as we first need to migrate all of Home Assistant integrations to follow this issue and then a potential packaged component proposal, before we can even think about implementing it. This is the last comment about packaged components on this issue, all others will be removed.