Sorry for the delay - I am not sure how to respond - but I am trying
to get through my e-mail backlog before winter break.
I think this could be kind of cool - stuff has been added to the top
of that tool run screen lately and probably more will be added soon. I
think an option to basically take the JSON that an API request would
take and populate the form would be possible and a lot easier now that
We had a tool developer meeting (which we probably should have
announced here on -dev instead of just on github in retrospect) and
one of the ideas that came out of that was the option to take an
existing tool run and basically extract a tool test XML block to stick
into the tool - I imagine the mechanism for doing tool parameter sets
could be similar.
It would also be something useful for disseminating say properties in
papers that is lighter than whole workflows or histories.
So I like it - but it is probably not a top priority for the devteam
at this time - happy to review pull requests though of course.
On Thu, Oct 16, 2014 at 4:15 AM, Lukasse, Pieter <pieter.lukasse(a)wur.nl> wrote:
I see that in my last email I replied to you with the fourth (and not the third) option
in mind :(.
Just to come back to this related to the third option (i.e. " Have a dummy tool to
produce a settings file and allow the users to choose this file when running the real
tool"): I don't like this option so much because the file is never as clear as
the tool form that produced it. If users are used to looking at the tool form for seeing
details about the set parameters and now they will have to look at a text file, this will
be confusing. It is not a huge problem, but it is one that I am trying to avoid. I.e. it
would be best if users are presented with only one way of checking parameters of executed
In the scenario I am proposing, the settings files are disseminated just as they are
(e.g. a text file) either by sharing them in the normal ways or by placing a number of
them in pre-defined folders in Galaxy. The tool form would allow the user to select one
and would then fill in the values of the parameters accordingly. I'm guessing similar
binding logic is also happening right now when a user clicks "rerun" on a step
in his history.
From: John Chilton [mailto:firstname.lastname@example.org]
Sent: donderdag 9 oktober 2014 15:45
To: Lukasse, Pieter
Subject: Re: [galaxy-dev] HOWTO share tool parameter settings?
How would this be different then the third option you listed?
You want it to work with all tools and you as the developer want to be able to construct
these files without needing a dummy tool to produce the values?
How would imagine these setting files would be disseminated to users and then selected by
On Thu, Oct 9, 2014 at 9:34 AM, Lukasse, Pieter <pieter.lukasse(a)wur.nl> wrote:
> Do we have a way (or plans) for sharing tool parameter settings in Galaxy?
> I know the following workarounds :
> · Share a history with all users: so users can import your step and
> do “rerun” to run on their own file with your settings
> · Wrap the step in a workflow with all parameters set and publish
> this workflow: users can run this “workflow”
> · Have a dummy tool to produce a settings file and allow the users
> to choose this file when running the real tool
> · Use a conditional and many macros that are basically a copy of
> each other, only differing in the parameter values
> But what I would like to have is a way to define bindings between a
> settings file and the parameters in the tool form. Any plans, ideas?
> Pieter Lukasse
> Wageningen UR, Plant Research International
> Department of Bioinformatics (Bioscience)
> Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB,
> Wageningen, the Netherlands
> T: +31-317481122;
> M: +31-628189540;
> skype: pieter.lukasse.wur
> Please keep all replies on the list by using "reply all"
> in your mail client. To manage your subscriptions to this and other
> Galaxy lists, please use the interface at:
> To search Galaxy mailing lists use the unified search at: