On Apr 19, 2012, at 10:04 AM, Peter Cock wrote:

> On Thu, Apr 19, 2012 at 2:32 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>> The tool shed forces unique repository names per user account, allowing for
>> uniqueness with that combination.  All tools uploaded into a tool shed
>> repository are assigned a unique id called a guid, which is unique for all
>> tools across all possible tool sheds.  These guids follow a named spacing
>> convention that ensures that any tool installed into any Galaxy instance
>> will be uniquely identified regardless of "old" tool ids or tool versions.
>> 
>> ... The "old"  id is still important and must
>> be included in the tool config as usual, but is not used to identify a tool
>> that is installed in a repository from the tool shed.
> 
> Ah - so the "old" tool ID clashes are only going to be a problem with
> Galaxy servers where the tools were installed 'the old fashioned way'
> (like ours).

Yes, it is highly recommended to install tool shed repositories using the 
installation process that has been implemented rather than downloading the 
repository contents as an archive and manually manipulating it to be 
incorporated into your Galaxy instance.  Using the installation process 
includes many benefits in addition to eliminating the potential tool id 
clashes.  Examples of benefits include not having to stop / restart your Galaxy 
server in order to use freshly installed tools, being able to deactivate / 
uninstall tools on-the-fly when finished with them, being able to run multiple 
versions of the same tool simultaneously in the same Galaxy instance, etc.


> So there is still scope for clashes with shared workflows -
> but this will be less and less of a problem as local Galaxy installs
> switch to installing tools via the Tool Shed?

Correct - if you manually download the contents of a repository and install it 
into your local Galaxy instance, there is no way to eliminate the potential for 
tool id / version clashes.  In fact, it may be beneficial to eliminate the 
feature enabling users to manually download repository contents, but we'll 
leave it there as long as the community wants it.

> 
> What happens if (for example) Brad gives Lance commit rights to
> his repository (or the other way round)? Then you'd have a clash.

Assuming automatic installation using the tool shed install process, no clashes 
will occur in this scenario, because no matter who pushes changes to the 
repository, it is still "name spaced" by the original owner, which can never 
change.  The only part of the guid that could potentially change is the tool 
version component ( e.g., 
toolshed.g2.bx.psu.edu/repos/brad-chapman/bam_to_bigwig/bam_to_bigwig/0.0.2 
becomes 
toolshed.g2.bx.psu.edu/repos/brad-chapman/bam_to_bigwig/bam_to_bigwig/0.0.3 if 
Brad gives Lance the ability to push to his repository and Lance change's the 
tool version ).

> 
>> All of these details are explained in the tool shed wiki in the following
>> section.
>> 
>> http://wiki.g2.bx.psu.edu/Tool%20Shed#Automatic_installation_of_Galaxy_tool_shed_repository_tools_into_a_local_Galaxy_instance
>> 
>> This section is also relevant to this discussion.
>> 
>> http://wiki.g2.bx.psu.edu/Tool%20Shed#Galaxy_Tool_Versions
> 
> Thanks for the background.
> 
> 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/

Reply via email to