On Wed, Jun 1, 2011 at 3:22 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Hi Peter,
Greg will probably reply, but I'll throw in my $0.02 as well.
Great - but with your answers you've triggered more questions ;)
Peter Cock wrote:
Hi Greg et al,
I've just been looking over your slides from last week about the new 'Galaxy Tool Shed', which are posted online here:
http://wiki.g2.bx.psu.edu/GCC2011
http://wiki.g2.bx.psu.edu/GCC2011?action=AttachFile&do=get&target=GalaxyToolShed.pdf
They talk about how you will be tracking individual tools in hg repositories.
I can see two ways this might work:
(1) Each of these tool specific repositories (or branches if you just make one repository for each tool owner) would be a full fork of the Galaxy code base. This allows in principle tools to include changes to core functionality (but that seems dangerous due to potential merge clashes), and any existing tool contributor's pre-existing hg forks on bitbucket might be reused.
The tool shed isn't really intended for framework changes - I would suggest keeping these as bitbucket forks, although it would certainly be good if we had a way to locate the list of such forks centrally.
Well, as long as the repository is created by forking on bitbucket, then the link existing in the bitbucket web interface. https://bitbucket.org/galaxy/galaxy-central/descendants
(2) Each of these tool specific repositories would ONLY track the tool specific files you'd add to Galaxy to install the tool. So, typically there would be an XML file, perhaps a wrapper script, maybe a sample loc file, and a plain text readme file.
I'm guessing you've gone for something along the lines of idea (2), but I
Yep.
It did seem the most likely route.
would love to hear more about how this will all work. e.g. Where would the tool shed repositories be hosted, and would tool authors use hg to work with them, or something like the current web based tool upload?
They're hosted here, and you can check them out and work with them locally as you do the Galaxy source itself, or use the new web-based upload to upload individual files or tarballs.
Have a look at the test instance of the next-gen toolshed here if you'd like to see how it works:
http://testtoolshed.g2.bx.psu.edu/
Please feel free to use this as a sandbox and report any issues you find.
I see the existing usernames and passwords from the old Tool Shed were transferred - that makes life easier. And it lists the hg information, e.g. hg clone http://peterjc@testtoolshed.g2.bx.psu.edu/repos/peterjc/venn_list hg clone http://peterjc@testtoolshed.g2.bx.psu.edu/repos/peterjc/tmhmm_and_signalp What happens with branches? Would the Tool Shed just show the default branch? That seems best for a simple UI. I have a query regarding the way the tools are shown in tables and the "version" column, which shows a changeset and revision number. According to Greg's slides (slide #10, titled "Simpler tool versioning" which seems ironic to me), the old numerical version is still there in the XML - and I'd prefer to see that. How about having both shown (two columns, perhaps call them "Public version" and "hg version" or "hg revision"). With regards to the planned installation functionality, what happens when a tool repository (aka Tool Suite in the old model) contains several XML wrappers - would you be able to choose which are wanted? The use case I have here is when several tools share some common dependency (which should be tracked in a single repository), and were therefore useful to bundle together as a suite, but where not all the tools will be of global interest (e.g. My TMHMM, SignalP, etc suite). Peter