Do ToolShed updates cope with renaming files?
Hi all, I'd like to check (before I try this), if is this expected to work or not? For the normal tool wrappers, is it possible to rename the XML file (but leave the tool ID inside the XML file unchanged), and have this *just work* (TM) when automatically updated via the ToolShed? Similarly, for the new 'blast_datatypes' Tool Shed entry, can I rename xml.py which defines the file format(s) to something like ncbi_blast.py (and update the datatypes_conf.xml ToolShed file to match)? My desire here is partly to avoid the current namespace clash with galaxy.datatypes.xml but also that I intend this to include other non-XML BLAST formats as well (e.g. BLAST database). Thanks, Peter
Hi Peter, On Sep 20, 2012, at 5:53 AM, Peter Cock wrote:
Hi all,
I'd like to check (before I try this), if is this expected to work or not?
For the normal tool wrappers, is it possible to rename the XML file (but leave the tool ID inside the XML file unchanged), and have this *just work* (TM) when automatically updated via the ToolShed?
Yes, this is possible (and works), but make sure to do the following: 1. Do not change the tool ID string nor the tool version string, just rename the tool config. 2. Make sure to upload the change as a tarball, and keep the following select list checked as "Yes". This means that you need to have everything in your tarball that you want to keep. The old tool config will be eliminated and the new, renamed one will replace it. Since the tool id and version remain the same, the "valid / installable" changeset revision will be reset to the new tip.
Similarly, for the new 'blast_datatypes' Tool Shed entry, can I rename xml.py which defines the file format(s) to something like ncbi_blast.py (and update the datatypes_conf.xml ToolShed file to match)? My desire here is partly to avoid the current namespace clash with galaxy.datatypes.xml but also that I intend this to include other non-XML BLAST formats as well (e.g. BLAST database).
This change should pose no problems. As you state, just make sure to change the repository's datatypes_conf.xml file accordingly.
Thanks,
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:
On Thu, Sep 20, 2012 at 2:16 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Peter,
On Sep 20, 2012, at 5:53 AM, Peter Cock wrote:
Hi all,
I'd like to check (before I try this), if is this expected to work or not?
For the normal tool wrappers, is it possible to rename the XML file (but leave the tool ID inside the XML file unchanged), and have this *just work* (TM) when automatically updated via the ToolShed?
Yes, this is possible (and works), but make sure to do the following:
1. Do not change the tool ID string nor the tool version string, just rename the tool config. 2. Make sure to upload the change as a tarball, and keep the following select list checked as "Yes". This means that you need to have everything in your tarball that you want to keep. The old tool config will be eliminated and the new, renamed one will replace it. Since the tool id and version remain the same, the "valid / installable" changeset revision will be reset to the new tip.
OK. What would happen if I did the rename and increased the version number in one step (which seems the most common situation)?
Similarly, for the new 'blast_datatypes' Tool Shed entry, can I rename xml.py which defines the file format(s) to something like ncbi_blast.py (and update the datatypes_conf.xml ToolShed file to match)? My desire here is partly to avoid the current namespace clash with galaxy.datatypes.xml but also that I intend this to include other non-XML BLAST formats as well (e.g. BLAST database).
This change should pose no problems. As you state, just make sure to change the repository's datatypes_conf.xml file accordingly.
Excellent - I'll try to do that rename operation today for the BLAST datatypes. Peter
Hi Peter, see below... On Sep 20, 2012, at 9:43 AM, Peter Cock wrote:
On Thu, Sep 20, 2012 at 2:16 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Peter,
On Sep 20, 2012, at 5:53 AM, Peter Cock wrote:
Hi all,
I'd like to check (before I try this), if is this expected to work or not?
For the normal tool wrappers, is it possible to rename the XML file (but leave the tool ID inside the XML file unchanged), and have this *just work* (TM) when automatically updated via the ToolShed?
Yes, this is possible (and works), but make sure to do the following:
1. Do not change the tool ID string nor the tool version string, just rename the tool config. 2. Make sure to upload the change as a tarball, and keep the following select list checked as "Yes". This means that you need to have everything in your tarball that you want to keep. The old tool config will be eliminated and the new, renamed one will replace it. Since the tool id and version remain the same, the "valid / installable" changeset revision will be reset to the new tip.
OK. What would happen if I did the rename and increased the version number in one step (which seems the most common situation)?
Assuming you want to increase the version number of the tool, this is fine. However, the version number should be changed only if the tool's behavior has changed such that different results are produced (from the previous version) if the same analysis is executed. Just changing the name of the tool config should not result in a new version of the tool. This is important because changing the version of the tool will result in a new installable changeset revision being set, which means that if someone installed the previous installable changeset revision (that included the old version of the tool), they will need to install the new revision rather than bein able to just get updates to the one previously installed. This behavior ensures that each version of a tool can be installed, ensuring reproducibility over time.
Similarly, for the new 'blast_datatypes' Tool Shed entry, can I rename xml.py which defines the file format(s) to something like ncbi_blast.py (and update the datatypes_conf.xml ToolShed file to match)? My desire here is partly to avoid the current namespace clash with galaxy.datatypes.xml but also that I intend this to include other non-XML BLAST formats as well (e.g. BLAST database).
This change should pose no problems. As you state, just make sure to change the repository's datatypes_conf.xml file accordingly.
Excellent - I'll try to do that rename operation today for the BLAST datatypes.
Peter
On Thu, Sep 20, 2012 at 2:52 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
On Sep 20, 2012, at 9:43 AM, Peter Cock wrote:
OK. What would happen if I did the rename and increased the version number in one step (which seems the most common situation)?
Assuming you want to increase the version number of the tool, this is fine. However, the version number should be changed only if the tool's behavior has changed such that different results are produced (from the previous version) if the same analysis is executed. Just changing the name of the tool config should not result in a new version of the tool.
This is important because changing the version of the tool will result in a new installable changeset revision being set, which means that if someone installed the previous installable changeset revision (that included the old version of the tool), they will need to install the new revision rather than bein able to just get updates to the one previously installed. This behavior ensures that each version of a tool can be installed, ensuring reproducibility over time.
I think I followed that - thanks for the clarification. Peter
participants (2)
-
Greg Von Kuster -
Peter Cock