Hi all, Is there an overall policy on default values when wrapping tools? e.g. Should defaults be set explicitly in the wrapper (which we can track in the Galaxy version control under hg), or omitted to let the command line tool set its own defaults? I am thinking about pipeline reproducibility as defaults can change... Peter
On Thu, Sep 30, 2010 at 11:08 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
Hi all,
Is there an overall policy on default values when wrapping tools?
e.g. Should defaults be set explicitly in the wrapper (which we can track in the Galaxy version control under hg), or omitted to let the command line tool set its own defaults?
I am thinking about pipeline reproducibility as defaults can change...
Peter
As an example which I hope clarifies this, looking at blastn and the dust option (ignoring for the moment the possibility to pass three values level window linker), we can do this: blastn ... -dust yes blastn ... -dust no or omit the dust option and let blastn follow its own default (which is to use dust). Before this patch, I was always explicitly setting the dust option; After the patch, in "basic" mode I let blastn follow its own default: http://bitbucket.org/peterjc/galaxy-central/changeset/1b9eefbd876a Maybe this is a minor issue and is just down to the preferences of the person writing each wrapper? Peter
Hi Peter, personally I think it is better to be explicit, in case the default value changes between versions of the underlying tool. -- jt James Taylor Assistant Professor Department of Biology Department of Mathematics & Computer Science Emory University On Oct 1, 2010, at 6:55 AM, Peter wrote:
On Thu, Sep 30, 2010 at 11:08 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
Hi all,
Is there an overall policy on default values when wrapping tools?
e.g. Should defaults be set explicitly in the wrapper (which we can track in the Galaxy version control under hg), or omitted to let the command line tool set its own defaults?
I am thinking about pipeline reproducibility as defaults can change...
Peter
As an example which I hope clarifies this, looking at blastn and the dust option (ignoring for the moment the possibility to pass three values level window linker), we can do this:
blastn ... -dust yes blastn ... -dust no
or omit the dust option and let blastn follow its own default (which is to use dust).
Before this patch, I was always explicitly setting the dust option; After the patch, in "basic" mode I let blastn follow its own default: http://bitbucket.org/peterjc/galaxy-central/changeset/1b9eefbd876a
Maybe this is a minor issue and is just down to the preferences of the person writing each wrapper?
Peter _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
On Fri, Oct 1, 2010 at 1:49 PM, James Taylor <james@jamestaylor.org> wrote:
Hi Peter, personally I think it is better to be explicit, in case the default value changes between versions of the underlying tool.
Understood... although this brings its own problems when people want the NCBI defaults and assume they'll get them, but in fact get the Galaxy defaults (which may have once been the same but are not anymore). I'm currently looking at some of the more complicated BLAST+ options, and the fact that some of these are mutually exclusive means I may be forced to leave things unset... fiddly. Peter
participants (2)
-
James Taylor -
Peter