I understand entirely, I too find it very difficult with various discussions going on in github “issues” across many repos, lost in the depths of the forum and of course those that go on behind closed doors in PM’s and emails because that’s the only way to have a proper discussion about these things, If only there was a place set aside for OEM developers to talk shop eg a “developers corner”.
It would be a generic (linux) emoncms installer/fixer, hopefully it would become part of the emonPi/Sd update routine, but it this script would be specific to installing/fixing emoncms, not the wider emonPi stack.
The second part is currently a generic “git repos updater”, you can list folders eg /var/www/html, /home/pi and /var/www/html/emoncms/Modules and it will look in each of those locations for folders with the .git folder. Those found are shortlisted and each is checked for a remote url and branch, that info is used to check for a version file in the root of that remote repo/branch.
There was a discussion about a version file verses a modules file, currently I’m drawn towards a version text file that only contains the version number alone, because the module.json has to be in the sub-folder for the “Modules” part of a module rather than the root. I also think the renaming the modules (using modules.json) is superfluous, we do not need pretty names on the admin page, what we need is to know “absolutely” what is installed, not what someone has decided would be the “friendliest name”.
For the purpose of demonstration. Here is a link to the “version” of the emoncms device module, master branch and to the device-integration branch of the same repo. Alternatively if I was running my own variant of that the remote could be my own repo and no that isn’t the nodes module it is still the device module, I just changed the name in the modules.json file to demonstrate the point I made above,
This is most useful when (for example) you are developing the groups module and ask for testers, I could switch to your repo and any thing you push could be pulled in by my install without having to avoid using any in-built “fixed” url/repo/branch updating methods.
Nothing to do with me! I have had no involvement with the emonPi updater and I would do things quite differently if I was to do it.
For completness here are a couple of links about the emonpi updater Update EmonPi Button or Update EmonBase Button? and Errors not reported in emonpiupdate.log file - #9 by pb66. I believe the flashing of an attached device should be a separate operation, triggered by the user. or at least a user setting whether it is included or not.
I have pondered on this before, and I believe there are too many moving parts, moving at thier own pace. yes there are multiple reasons to use a cronjob, there are also scripts for the mqtt_input and for buffered write, not to mention the many calls for a way to notify when feeds are not updating, plus there are many good reasons to include processing that doesn’t depend on an input to trigger it, eg summing the power of 3 phases from 3 devices, how do you ensure that processing continues if ANY one phase goes down? Sod law says the phase that goes down will be the one that you chose to put your processing in and is no longer being triggered. I wonder if the time is here for a single emoncms daemon that handles all of the above.
No not currently, It is dependent on the version file content only. I am one the fence about local changes too. On one hand I’m thinking the script should just raise an error for the user to stash the changes (easiest) or automatically stash and reapply changes (quite difficult and may transfer old issues to new updated code) or just ignore and reset changes (perhaps stashing them in case the user wants to reapply them). none is ideal, there could be a user setting to define what happens. At the end of the day, any other (non-git pull) method would just overwrite changes without checking so any improvement on that could be a bonus.
I see your point, but I think we have 2 choices, we embrace choice and give users the ability to make selections or we hardcode everything, removing a lot of choice and almost adopting a “do it all our way or figure it out for yourself” type attitude, because if a user wants to make changes to a module and run his own repo, he might not be able to use the updater for the other repos. The result is many users just stick with whats easier and don’t explore or contribute because straying away from the norm is too involved, eg the emonPi/SD.