I’m looking to migrate my Wiser platform from HACS to mainline HomeAssistant but I’ve been hit by the rule that a single PR should only contain one platform … Sure for regular PRs but not an initial one surely.
The current incarnation of the integration is quite advanced and serves a number of users already using HACS as the deployment mechanism… Ive been told that to publish it I need to issue a number of PRs, probably 4, each one with only one platform… .
Is this truely necessary? Its a lot of work for all and additionally will take time to publish each and every PR one at a time (no point in issueing PR#2 until I know PR#1 is approved)…
Im tempted to just stay on HACS where things are a lot easier… …
I think the answer is no…
The platforms are all there to support the wiser heating system and whilst they do work independently they all share a common infrastructure and work together.
Agree, but it strikes me as strange , this is a community effort and thus we (the community) should be able to influence the rules and guidelines.
What I am proposing is that for mature integrations, the first PR, we should allow multiple platforms, for subsequent PRs then sure, they need to be piecemeal.
The way I looked at is was I used HACS to test my idea/integration out, see if it works, has general interest and develop it - think of it as an incubation hub like apache incubator. Now that Ive determined that yes it has legs I went back and fixed all the code /docs/style to match HAs native guidelines…
What I am now being asked to do is break the integration in multiple pieces, and wait for each one to be approved before I submit the next one (im not going to submit pr2 until i know pr1 is resolved…)
Just doesnt sound very community friendly to people moving from an incubator like HACS to mainline HA…
I can do the changes though, just not very attractive to break my current install base
Could be very valuable to have core developers team point of view and share the conclusion & rules to developers. If similar cases are planned we can anticipate difficulties.
It could mean it could be more interesting to start developing our MVP in Home Assistant/core and improved it from one version to another.
My first intention was more to improve in HACS and then migrate to core.
HACS isnt a incubator to move to core, that was never its intention it just allows for easier installation of custom integration At the end of the day its the core developers who have to maintain the main HA development so they have the final say on how anything is integrated.
Personally i would remove all integrations from the core and have them like custom integrations are now, Then users can install only those they require, that way the onus isn’t on the core developers to maintain the integration when they have been abandoned or not updated.
@aidbish I totally agree, I do think the HACS approach (package manager style) should be adopted by HA core… thats how most other software works (windows,linux, chrome, etc)…
It would actually allow the HA developers to focus on the core HA platform and not keep track of 3rd party integrations.
I simply wanted to move it to HA Core so that it has a wider audience, people first look in HA Core for integrations and then HACS or google…
BUT that said it is what it is… I think the rule that PRs should only contain one “thing” (platform, code fix etc) should be relaxed for the initial PR of a new integration…
How do I raise this “officially” with the HA Core developers? An issue?
I understand you point of view but I don’t share it.
For me having them included in core is clearly a visibility advantage. On top of that it allows other contributors to help maintaining the integrations. For integration PR, the developer core team is there to check the updates are compliant with architecture and golden rules. If you need to change an architecture having the integration included in core allows to implement the updates in batch.
With HACS if an owner has availability difficulties it will be difficult to have the PR merged and deployed in HACS. On the other hand I recognize the main advantage of HACS to be able to deploy quickly updates asynchronously of the HA core release schedule: when the owner is engaged and available it’s a huge value for the users.
Where we seem to all agree is to clarify the rules and perhaps release some constraints for initial PR for a new integration.
This is all my opinion based on having provided both HACS integrations and core integrations.
I would say the juice is worth the squeeze in that the code review to get an integration into core will make your integration better and more robust. This is my experience. Plus, it is easier for the end user - no need to separately update integrations in HACS, version incompatibilities could be tough to manage for both developers and users in some cases. etc.
One problem, in my view, is that there aren’t enough reviewers of the PRs for core and there is an extreme backlog of PRs to get through already. If there were only 10 open PRs, it wouldn’t be such a hurdle to review a larger code addition. You could help out by reviewing existing PRs to reduce this problem.
Moreoever, the fact that the integration is ‘mature’ in HACS does not mean that it conforms to the standards of integrations in the core and may still require significant restructuring. This is easier to do if the simplest, most essential PRs are submitted first.
understand the views here and I’m not against splitting the PR but it will break existing users badly… especially if the PRs take ages/long time to go through the system.
Also , once I decided to move it to HA Core I did go through the code and get it to conform to the HA standards, which I agree is a good thing
If possible, you can try to make the core integration not break the HACS integration, e.g. use a different domain name. Then, the existing users can keep using it while it is is being implemented piece by piece.
Actually I don’t think you have to change the domain. According to where home assistant looks for integrations if there is a custom component with the same domain as a core component then the custom component will override the core one. They obviously don’t recommend overriding core components but it seems like the perfect solution in this case. Your development process can basically go like this:
Create a new integration in core with the same domain. Begin moving the likely long process of moving the custom component into core over a series of PRs.
Your existing users continue to use the installed custom component over the core one as long as they have it installed. Recommend they track the core component for updates and uninstall the custom component once all features they use have been implemented in the core component
Deprecate the HACS component once the component has been fully moved over to core.