A tool with no inputs
One of my colleagues is having trouble developing a peculiar tool: it has no inputs. This makes sense in our local context - it fetches some constantly updating remote data for the current user - but implementing it has escaped our skill. Galaxy complains about a tool with no params (i.e. an empty <inputs>). It complains about a tool with no <inputs> tag. Hidden input fields don't seem to work (i.e. looks like I'm getting the cached value of the form). It is admittedly a fairly niche use-case and we could put in a dummy field and simply not use it, but that seems inelegant. Any suggestions? ---- Paul Agapow (paul-michael.agapow@hpa.org.uk) Bioinformatics, Centre for Infections, Health Protection Agency ----------------------------------------- ************************************************************************** The information contained in the EMail and any attachments is confidential and intended solely and for the attention and use of the named addressee(s). It may not be disclosed to any other person without the express authority of the HPA, or the intended recipient, or both. If you are not the intended recipient, you must not disclose, copy, distribute or retain this message or any part of it. This footnote also confirms that this EMail has been swept for computer viruses, but please re-sweep any attachments before opening or saving. HTTP://www.HPA.org.uk **************************************************************************
Doesn't this violate one of the basic tenets of Galaxy - reproducibility? Without the ability to provide full traceability to the inputs, one can make no guarantees about the outputs. John Duddy Sr. Staff Software Engineer Illumina, Inc. 9885 Towne Centre Drive San Diego, CA 92121 Tel: 858-736-3584 E-mail: jduddy@illumina.com<mailto:jduddy@illumina.com> From: galaxy-dev-bounces@lists.bx.psu.edu [mailto:galaxy-dev-bounces@lists.bx.psu.edu] On Behalf Of Paul-Michael Agapow Sent: Monday, May 16, 2011 7:45 AM To: galaxy-dev@lists.bx.psu.edu Subject: [galaxy-dev] A tool with no inputs One of my colleagues is having trouble developing a peculiar tool: it has no inputs. This makes sense in our local context - it fetches some constantly updating remote data for the current user - but implementing it has escaped our skill. Galaxy complains about a tool with no params (i.e. an empty <inputs>). It complains about a tool with no <inputs> tag. Hidden input fields don't seem to work (i.e. looks like I'm getting the cached value of the form). It is admittedly a fairly niche use-case and we could put in a dummy field and simply not use it, but that seems inelegant. Any suggestions? ---- Paul Agapow (paul-michael.agapow@hpa.org.uk) Bioinformatics, Centre for Infections, Health Protection Agency ________________________________ ************************************************************************** The information contained in the EMail and any attachments is confidential and intended solely and for the attention and use of the named addressee(s). It may not be disclosed to any other person without the express authority of the HPA, or the intended recipient, or both. If you are not the intended recipient, you must not disclose, copy, distribute or retain this message or any part of it. This footnote also confirms that this EMail has been swept for computer viruses, but please re-sweep any attachments before opening or saving. HTTP://www.HPA.org.uk **************************************************************************
On Mon, May 16, 2011 at 4:53 PM, Duddy, John <jduddy@illumina.com> wrote:
Doesn’t this violate one of the basic tenets of Galaxy – reproducibility? Without the ability to provide full traceability to the inputs, one can make no guarantees about the outputs.
Yes, but not everyone puts that as a number one priority for their use of Galaxy. Also given software inevitably changes, the version of the underlying tools on a Galaxy server is potentially in flux. As another example, we have local copy of the NCBI NR BLAST database setup as nr, which is kept in sync with the latest releases. This implicitly means any workflow using this database (e.g. identify novel proteins, those with no matches against NR) can give different results as the database changes. IIRC the Galaxy documentation suggests using multiple copies of a database, each date stamped, to try and ensure reproducibility. Anyway, tools with no inputs was brought up at the end of last year: http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-November/003812.html http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-December/003955.html ... http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-December/003974.html Peter
Yes, as referred to by Peter we solved this by having a single radio-button and some dummy text. If you just have a single radio it doesn't show up and only displays the text. So it basically just gives me the execute button. Snippet attached below; We used it for a tool that refreshes some data. Alex <tool id="REFRESH_DATA" name="RefreshDataSets" Version="1.0.Alx" force_history_refresh="True"> <description>: Data refresh Tool</description> <command interpreter="python"> refreshData.py $input $output </command> <inputs> <param name="input" type="select" display="radio" size="250" label="Dynamically Refresh the Data" /> </inputs> <outputs> <data format="tabular" name="output" /> </outputs> <tests> </tests> <help> Yeaah something here :) </help> </tool> [end] ________________________________________ Van: galaxy-dev-bounces@lists.bx.psu.edu [galaxy-dev-bounces@lists.bx.psu.edu] namens Peter Cock [p.j.a.cock@googlemail.com] Verzonden: maandag 16 mei 2011 18:11 Aan: Duddy, John CC: galaxy-dev@lists.bx.psu.edu Onderwerp: Re: [galaxy-dev] A tool with no inputs On Mon, May 16, 2011 at 4:53 PM, Duddy, John <jduddy@illumina.com> wrote:
Doesn’t this violate one of the basic tenets of Galaxy – reproducibility? Without the ability to provide full traceability to the inputs, one can make no guarantees about the outputs.
Yes, but not everyone puts that as a number one priority for their use of Galaxy. Also given software inevitably changes, the version of the underlying tools on a Galaxy server is potentially in flux. As another example, we have local copy of the NCBI NR BLAST database setup as nr, which is kept in sync with the latest releases. This implicitly means any workflow using this database (e.g. identify novel proteins, those with no matches against NR) can give different results as the database changes. IIRC the Galaxy documentation suggests using multiple copies of a database, each date stamped, to try and ensure reproducibility. Anyway, tools with no inputs was brought up at the end of last year: http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-November/003812.html http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-December/003955.html ... http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-December/003974.html Peter ___________________________________________________________ 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: http://lists.bx.psu.edu/
Thanks for the workaround, Alex. If you want to follow the resolution of this bug, see here: https://bitbucket.org/galaxy/galaxy-central/issue/463/cannot-have-a-tool-wra... Apparently, it is not as trivial as it seems to fix. Florent On 17/05/11 03:32, Bossers, Alex wrote:
Yes, as referred to by Peter we solved this by having a single radio-button and some dummy text. If you just have a single radio it doesn't show up and only displays the text. So it basically just gives me the execute button. Snippet attached below; We used it for a tool that refreshes some data. Alex
<tool id="REFRESH_DATA" name="RefreshDataSets" Version="1.0.Alx" force_history_refresh="True"> <description>: Data refresh Tool</description> <command interpreter="python"> refreshData.py $input $output </command> <inputs> <param name="input" type="select" display="radio" size="250" label="Dynamically Refresh the Data" /> </inputs> <outputs> <data format="tabular" name="output" /> </outputs> <tests> </tests> <help> Yeaah something here :) </help> </tool>
[end]
________________________________________ Van: galaxy-dev-bounces@lists.bx.psu.edu [galaxy-dev-bounces@lists.bx.psu.edu] namens Peter Cock [p.j.a.cock@googlemail.com] Verzonden: maandag 16 mei 2011 18:11 Aan: Duddy, John CC: galaxy-dev@lists.bx.psu.edu Onderwerp: Re: [galaxy-dev] A tool with no inputs
Doesn’t this violate one of the basic tenets of Galaxy – reproducibility? Without the ability to provide full traceability to the inputs, one can make no guarantees about the outputs. Yes, but not everyone puts that as a number one priority for their use of Galaxy. Also given software inevitably changes, the version of the underlying tools on a Galaxy server is potentially in flux. As another example, we have local copy of the NCBI NR BLAST database setup as nr, which is kept in sync with the latest releases. This implicitly means any workflow using this database (e.g. identify novel proteins,
On Mon, May 16, 2011 at 4:53 PM, Duddy, John<jduddy@illumina.com> wrote: those with no matches against NR) can give different results as the database changes. IIRC the Galaxy documentation suggests using multiple copies of a database, each date stamped, to try and ensure reproducibility.
Anyway, tools with no inputs was brought up at the end of last year: http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-November/003812.html http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-December/003955.html ... http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-December/003974.html
Peter
___________________________________________________________ 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:
___________________________________________________________ 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:
participants (5)
-
Bossers, Alex -
Duddy, John -
Florent Angly -
Paul-Michael Agapow -
Peter Cock