Hi, I am trying to guide a newly formed dev team who have come together to ensure that a custom_component survives and thrives. Ultimately the goal is to move to an Integration that is part of the HA codebase, by following the dev docs.
However I would like to know whether any experienced HA developers think it might be worth the time and effort to prepare and publish the Integration on HACS first. Would you recommend going straight to the main codebase or pushing to the community store first?
I appreciate you sharing your experience with us - thanks.
In my experience:
If you are unsure whether your integration behaves the way your users want it to behave, do a “test/feedback” release on HACS first. This way it is not that bad if you have to do several breaking changes until most are satisfied. For official integrations which are part of core users are often revolting when there is a breaking change.
For new features which do not alter the way the integration behave or change existing configuration options, you can always deliver them later on with more PRs to the core.
Agreed. Also it’s a LOT easier to control your own destiny with a custom integration. Once you submit it to the main code base you can’t simply do whatever you want anymore. So until you like it and it’s pretty much complete, you’re way better off releasing as a custom integration. The downside, of course, is it gets much less visibility/feedback.
Many thanks to @eifinger and @pnbruckner for your clear advice on the advantages of staging an Integration through HACS before taking it to the main codebase.
I’m just wondering if there are any developers out there who could argue the opposite? That spending time getting their component delivered to HACS was a distraction that took up valuable time away from merging with core, but without returning any benefit to the team or the users
Please do let me know if you think it would be a mistake for us to do that. Thanks
Great advice from Phil. On the backend channel I got Mr HACS himself explain why NOT to bother with HACS
(reasons to go straight for a core PR:)
Ludeeus
Your code will get reviewed, and when merged it will be available for all Home Assistant users.
I could probably go on and on about issues with publishing a custom_component (with or without HACS), there are somethings that should not be part of “core”, but those are few.
My advice is you should create your integration with the aim of getting it into the “core”, if you want to “betatest” with some form of distrubution system be my guest, but as long as the end goal is to make a PR to have it in “core” why not do it right away by making a PR?
But then on the #devs_general, aside from just feeling like I was learning useful stuff just by reading the banter, I came across an interestingly compelling case to not rely on just doing the PR thing…
paolog89 (10 Jan 2020 at 12:38)
Hello all, I have a really small commit that hasn’t been reviewed since October.
How can I move it forward?
balloob
patience paolog89. We’re slowly working through our backlog
Although this is an extreme case I did see a lot of 'can you pull my request please’s so perhaps our answer is to carve out a middle path, doing both! I wonder if I can find a way to keeping taking steps towards a PR for core, whilst happening to pass though HACS on the way there.
It seems like the most viable long-term strategy for Home Assistant integrations is to actually split most of all except the most basic out as custom_components, and to incorporate HACS (or a replacement) directly into Home Assistant.
a large percentage of the patches to Home Assistant after major releases seem to be fixes to various integrations
the time overhead of managing all the integrations by the core Home Assistant team
ability to quickly fix broken integrations is critical, rather than waiting weeks, for a variety of reasons
individual integrations (especially new ones) may need more rapid change than is feasible within HA
device manufacturers can rollout firmware updates (at any time) that could break the HA integration…being able to quickly respond is critical
security vulnerabilities may need to be quickly addressed (outside the HA release schedule)
the ability to rollback to older versions of integrations can be useful (rather than always having to accept the latest)
all the integrations that are core to HA today are loaded on startup: slowing down boot, taking up more memory…which are both unnecessary
Ideally, the core integrations would have some sort of acceptance factor before they are included. For instance, if 30% of the recently running Home Assistant instances worldwide are using a given integration, then perhaps it should be included. Any that are used at lower than 30% should be kicked out to the default set of custom_integrations.
One solution to this may just mean splitting out “core” custom_integrations into its own set that is still code reviewed, has a regular release schedule, etc. There doesn’t have to be a all in HA core, or all HACS. There can be middle ground that might be more effective for all scenarios.
