There are several discussions around this topic. I started this thread to try and pull the various bits of discussion together.
I have always used a “emoncms installer” script to install emoncms from one command, previously I have not made that publicly available because it doesn’d fully comply with the current documentation and the way things are done on the emonSD image.
More recently I wrote a simple bash script for updating emoncms and the emoncms-modules that was shared and it was the precurser to the way the emoncms modules are currently listed on the admin page in emoncms (see Admin display currently installed Emoncms modules), That script can also be found in emoncms/usefulscripts.
That script has evolved quite a bit since then and now checks for updates rather than doing a blind pull, it is also branch and remote specific, this means it will determine the existing remote url for the repo and check there, for updates to the branch currently in use and update from there if updates are available (or blindly pull in IF it cannot find a “version file” so this can work on repos that have not yet had a “version file” created).
There is a discussion on github about implementing the “version file”.
Much of this work has stalled due to recent discussions about the emoncms installation docs, emoncms dependencies and the best file structure for emoncms to facilitate easy installation, upgrading, support, documentation, debugging and at the same time hopefully make the installation more IFS compliant and also uniform across various linux distros, incl RO Raspbian like the emonSD image.
My intention was to arrive at 2 scripts, the first would install emoncms (and defined modules), this script will ideally would be “multi run safe” so that any failed/interrupted installs could be completed by simply running the installer again, another benefit of this is that it could be used to “fix” issues, such as missing (accidentally deleted) symlinks, re-enabling php and apathe2 modules eg mod-rewrite and correcting file permissions such as the phpfina folders and the log files etc. The second script would be for updating the existing installation without having to hardcode the remote repos or branches, in fact I have kept this so generic (so far) that it would work for all git repos if located in a known place, here I’m thinking about all the FW repos and emonpi and emonhub etc that are not emoncms modules. even personal bespoke repos could be updated by this one updater.
Eventually I intended the updater to be triggered from within emoncms pretty much like the existing emonpi update is and more recently I thought the installer could also be triggered from within emoncms, obviously it cannot install emoncms from within emoncms, but it can fix things like permissions etc and if the “defined modules” list had been edited it would add any additional modules so it is useful from within emoncms.
I have primarily focused on external scripts, with an aim to trigger from within emoncms, purely because my php coding skills are not up to doing something more elaborate on my own.
@cagabi appears to be doing something quite similar but from a different angle, in the form of a emoncms module. So rather than contaminate his thread with all of the above I have written this to outline current development in hope we can collaborate rather than duplicating work or possibly trying to lead the project in different directions.
The issues discussed in that thread relating to permissions and ownership could be addressed by triggering (my?) external scripts and the approach I have taken tackles the backend of honoring existing branch and remote repo urls, but a module could allow a way of selecting branches (as suggested by @glyn.hudson) and defining the remote url plus maintain a list of “defined modules” for the installer script.
I like the idea of putting this all in a emoncms module and it should be possible to reuse the code I have written from within emoncms either via a flag and cron check like the current emonPi updater or possibly via an elevated user command like the “shutdown” in emoncms for the emonPi.
It would be quite simple to separate my updater checks from the updates themselves so that the checks run more frequently (automated) and the user can be kept informed and elect to update or not, there could also be an optional “keep fully updated” function that automatically installs updates as they become available.
Te able to do the complete job I would like to see an admin user only level api to update the database when there’s a schema change, currently the emonpi does this via a backdoor using php, that could be replicated, but I think a proper api call might be better.