Hello all, Re: BitBucket Issue 538 - Admin action to reload ".loc" files without restarting Galaxy https://trello.com/card/538-admin-action-to-reload-loc-files-without-restart... Currently Galaxy administrators can reload a tool's XML configuration file, which is very helpful (especially as a developer working on changes to a single tool). Similarly it would be useful to be able to reload one (or all) of the *.loc files (e.g. if a new BLAST database is added), without having to restart Galaxy. Further to this, it would be useful to trigger this from a script via the Galaxy API or otherwise. Should this be filed as a new issue, or a comment on the existing issue? Another idea for enhancement would be to monitor the loc files for *automatic* reloading without user or script intervention (but that might be too much magic), or simply (re)loading loc files on demand rather than at startup. Do the Galaxy team have any plans in this area? Thanks, Peter
On Fri, Mar 1, 2013 at 2:55 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hello all,
Re: BitBucket Issue 538 - Admin action to reload ".loc" files without restarting Galaxy https://trello.com/card/538-admin-action-to-reload-loc-files-without-restart...
Currently Galaxy administrators can reload a tool's XML configuration file, which is very helpful (especially as a developer working on changes to a single tool). Similarly it would be useful to be able to reload one (or all) of the *.loc files (e.g. if a new BLAST database is added), without having to restart Galaxy.
Further to this, it would be useful to trigger this from a script via the Galaxy API or otherwise. Should this be filed as a new issue, or a comment on the existing issue?
Another idea for enhancement would be to monitor the loc files for *automatic* reloading without user or script intervention (but that might be too much magic), or simply (re)loading loc files on demand rather than at startup.
Do the Galaxy team have any plans in this area?
Thanks,
Peter
One example I had in mind was a tool using a loc file for a list of databases, with a special entry "latest". If told to use the latest DB, the tool would check the source website/FTP site. If the latest file is already downloaded locally, it would just use that. If not, it would download the latest file and use it. That part is all quite doable in a tool wrapper script (assuming write permissions in the desired database folder). Now for the 'clever' part - the new database could be added to the loc file for explicit selection by future users. It could be added at the top to make it the default if desired. Then somehow we'd need Galaxy to reload the loc file. Of course, from a reproducibility point of view, the 'latest' version of a database is not ideal (especially when there are versioned or dated snapshots), but it is commonly requested all the same. Peter
participants (1)
-
Peter Cock