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/