On Wed, Jun 1, 2011 at 3:22 PM, Nate Coraor <n...@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://pete...@testtoolshed.g2.bx.psu.edu/repos/peterjc/venn_list hg clone http://pete...@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 ___________________________________________________________ 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/
