I have a tool with config templates (text files, are in the tool’s repo & docker image), and I wanted to allow the users to download said templates, prior to running the tool (and make it an obvious step). They can then edit the templates accordingly and re-upload them as input files. I am new to Galaxy dev and was wondering if there was a way to add a button similar to “Run Tool” that would trigger that download? So far my workaround has been a link to the repo in the help, but I was hoping to avoid that (since the files are in the docker image, I was hoping that they could be downloadable from it…?).
I don’t know of a way to do exactly that but maybe someone else reading over the next days will!
What I can think of:
Put the template into the Data Library on the host server.
Or, put a link to the tool and a link to the template somewhere on the homepage of the host server (welcome page).
Link from the Help (as you are doing it now – this would allow it to flow out via Tool Shed installations!)
Add in a “Step1: generate templates” mode to the tool form. This would be like a dry-run that doesn’t take any inputs and just has the tool write the template(s) into the history as output datasets. Then “Step2: run tool” is the actual tool run toggle mode.
I’ve seen this with other tools partially – this is the example I can think of off hand: Manta. It runs and uses a default configuration, and writes that to the history and the user can adjust it. That could have been a toggle at the top to only write that configuration file, with no required inputs.
Small warning that this kind of unusual usage can be frustrating for users – so, be nice and explain what to do, and make it hard to do the wrong thing, and error trap with human readable “what to do” messages for obvious misusage situations!
I’m not sure how you want them to edit the files. In Galaxy? That would avoid the common types of text editor errors people run into from using Notepad and similar apps. Galaxy has an Editor (see Visualizations tools). I guess you could include instructions for Text Manipulation tools (reproducible, where Editors are not), or even create a mini-workflow to edit the templates for them. Maybe they enter the values on the workflow runtime form as prompted values, so there isn’t even any workflow editing. But you decide of course! At that point you might as well put the values on the tool form!
Anyway, I hope this gives you some ideas and others are welcome to add more!
I should clarify that the current tool I am working on will be deployed on a private instance of Galaxy, and that managing user training and etc is easy since they do some testing for me (additionally, I have an extensive config validation step to account for typos and such, and the configs are saved with the outputs for proper archiving & tracing issues). But like I said, I really like the flexibility of the Mantra dropdown system.
@jennaj already answered this better and in a more exhaustive way than I ever could.
Just one additional point regarding your template files living only inside the docker image:
why not deposit them on some public server where they are easy to download?
A typical such place nowadays would be zenodo.org, which we are using for hosting training data and much more. Then your tool help can just link to the zenodo record.
@wm75 Thank you for answering! I was more wondering about linking the files with an html ref in the help to the internal docker path of the files (since they exist in the image). This would ensure absolute control of the version of the templates (they would be the same version as the docker image).
I think you should look at this the other way round and strive (assuming it’s you who is building the images) for reproducible builds using the e.g. zenodo-deposited files, but that’s really just a suggestion.
