Potential restructuring of project
artmg opened this issue · 18 comments
The proposal from @foxy82 and @robchandhok in issue #30 is:
- a main home-assistant project that has all the features of this project, and the documentation to install it manually, but that is also compatible with the third party 'Home Assistant Community Store' (HACS)
- a separate repo that contains the pypi component
My key goals. and concerns in doing this would be to:
- ensure that people who have a working implementation now can smoothly migrate to it working in the new scenario, or in some way just carry on as they are
- bring forward as much of the history, the issues and the documentation as we can into any new structure
- set up the pypi project with any workflow required to ensure that changes there become available via the live pypi channels
Please add any concerns or suggestions you have into comments in this issue, so that we can work together on the best way forward for the user and developer community around this project.
Thank you for your contributions.
I don't see this as a major change. You just have a slightly different folder structure, and those that prefer a manual install can just copy from that folder. If you do the move in git, the histories all stay the same.
No other integration, custom or otherwise, that I use in Home Assistant does it any other way. This project is the only one.
My key goals. and concerns in doing this would be to:
- ensure that people who have a working implementation now can smoothly migrate to it working in the new scenario, or in some way just carry on as they are
- bring forward as much of the history, the issues and the documentation as we can into any new structure
My feelings:
- I'm fine with HACS and at this point I'd prefer letting HACS manage the custom component. I also don't think I've seen any HACS project that couldn't also be installed manually. I resisted HACS for a while because it seemed like a bigger thing to install than it reall ways. So now I let it manage all the custom integrations I have and notify me when there are updates. Updates to this code have been so infrequent, I doubt changing the manual install procedures are going to be much of a burden.
- I think it would be a mistake to move to a new repo. Can't we just continue here? Any idea how many people are actually using this? Make a branch that has this current state before rearranging the file structure to meet HACS' requirements. Maybe make a "release" of the current state of this repo, so if anyone needs they can still download a tarball.
With regards to getting a current warmup4ie module into (back into) pypi, is the module stable / usable enough to be worth it?
I've seen other Hass custom integrations that have gone through this cycle and pulled the python module into the same repo as the hass integration just to make it easier to iterate on the code and make sure the module and the addon stay in sync. I do not believe having the base module in pypi is a requirement for HACS.
The main problem with this integration is that there is so little inertia and development interest. So anything that minimizes work for someone willing to contribute development cycles would most likely be the most beneficial.
I still use this daily but mainly to read temps as home assistant isn't really setup to manage heating schedules (at least as far as I've seen).
The suggestion for splitting the module and the custom component (hacs) would mean that potentially people outside of Home Assistant could use it and contribute. It also means that people that are "warmup api" experts can work on that and people that are "home assistant component" experts can work on that.
However I'm easy. Regards to breaking existing installs....if people mostly have this installed as a custom component then they have a copy so it won't break for them?
The suggestion for splitting the module and the custom component (hacs) would mean that potentially people outside of Home Assistant could use it and contribute. It also means that people that are "warmup api" experts can work on that and people that are "home assistant component" experts can work on that.
To be clear there already is a Python warmup4ie module: - https://pypi.org/project/warmup4ie/
I don't know how much version 0.1.5 from May 2019 has diverged from what's in this repo.
Yes, there should ideally be an up-to-date warmup4ie module in pypi. That is the right thing to do in the long term.
However the argument I'm making is that for the short term (and when someone does step up to do the work to fix issues with this integration and the module itself) it will be more work and harder to iterate on the code and get people to test if you need to get updates into pypi and get people to then install the update custom component.
However I'm easy. Regards to breaking existing installs....if people mostly have this installed as a custom component then they have a copy so it won't break for them?
Yes, that's a very good point.
Also I see @artmg has made a release on this repo (23.02), so that's another way if someone has problems with the HACS reorg they can get the previous release.
Thanks @artmg and everyone working on this. Looking forward to seeing the results.
I don't know how much version 0.1.5 from May 2019 has diverged from what's in this repo.
The repo that commits to that project hasn't changed since that 0.1.5 release. We have 3 extra commits here that they don't have which includes better support for multi thermostats, getting more data like air temperature and set override support.
https://github.com/ha-warmup/warmup/commits/master/warmup4ie-PyPi
Best would be to ask if we can takeover that pypi project. Publish it from this repo and the original author as well as others can work from here. We could also publish our own (renamed) package.... especially now we seem to also support the warmup 6 thermostat from some reports. Maybe warmup_ufh?
We can keep both the custom component and the package in this GitHub org so they are both close together?
Thanks for your advice and suggestions. I have begun by creating #51 a new dev branch ha-warmup:hacs-restructure that should now be usable. I will continue improving this with documentation changes, and then once you guys think it is ready we can pull that into master.
I manually pulled in the new dev branch ha-warmup:hacs-restructure into custom_components and restarted.
All seems well.
Thanks, @rct. I welcome other test results, whilst I rejig the docs. Then hopefully we will be ready before to long to pull this as the master version, and all be working off one base.
So, I have completed document changes and pushed this release candidate into the ha-warmup:dev branch.
With regards to the warmup4ie-PyPi package, I have updated this project's wiki page on PyPI-packages with the considerations you made above. Previous attempts to reach out to PyPI publishers have not materialised, and I agree that creating our own warmup_ufh might bring a lot more effort than value. For now I propose we simply stick to keeping the code inside the custom_components/warmup/warmup4ie folder, and manually replicating the few changes we make into the root warmup4ie-PyPi folder.
If everyone else is happy with the code and docs in dev then I can tag it and release it to master.
Assuming you are looking for feedback so you can merge to master?
It all looks good to be. I've been running the hacs-restructure branch without issue. I'm now on the dev branch, but the only thing that has changed is the manifest.
I skimmed the README in dev, it looks ok.
I think you've very safely covered things, so my vote is to get this merged into master.
Thanks for all your work on this.
Thank you @rct for your QA on this - now released to master - I appreciate another pair of eyes so that I wouldn't mess things up.
This is now done, I'll just clean up issues and point to this as the main repo from the old forked hacs-warmup
Thanks to all who have contributed and supported this
Assuming you are looking for feedback so you can merge to master?
It all looks good to be. I've been running the
hacs-restructurebranch without issue. I'm now on thedevbranch, but the only thing that has changed is the manifest.
So the update to the manifest that changed the version to 2023.3.15-beta caused a problem loading the warmup integration reported in #55.
I didn't catch that because when I saw that the only thing that changed was the manifest and no actual code, I thought I'd be safe not restarting Home Assistant. My apologies for not catching that.
Note if anyone did the same, and pulled in either the updated dev branch or the updated main branch, check custom_components/warmup/manifest.json, make sure version doesn't contain -beta. Otherwise Home Assistant won't load warmup next time you restart.
now retro-fixed in master branch, and CONTRIBUTING mentions the file as a reminder - thanks
@artmg - You may need to re-release this as I think the 2023-03-19 release from yesterday has the broken manifest.
@artmg First, thank you for doing this, @foxy82 and @rct as well! I am on travel so wasn't able to git in fast enough to test.
I had a few minutes this morning and did try the new release and I agree with @rct - the 3.19 release has the broken manifest. Also, you could now update the HACS instructions in the readme since you have made it into the HACS store (no need to add the custom repository anymore, very cool!).
Re-released. I will double-check the direct availability in HACS store before updating the ReadME
Confirm that 3.22 build works out of default HACS library. Thanks @artmg !