Helo Peter and Ira, These are great ideas and contributions, and I'll make sure to incorporate some version of them into the Tool Shed framework as soon as possible. I've created the following Trello card for this.
Thanks! https://trello.com/card/toolshed-enable-dependency-definitions-across-tool-sheds/506338ce32ae458f6d15e4b3/838 On May 6, 2013, at 11:05 AM, Peter Cock wrote: > On Thu, May 2, 2013 at 10:24 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: >> On Thu, May 2, 2013 at 7:16 AM, Ira Cooke <iraco...@gmail.com> wrote: >>> Hi all, >>> >>> I've written a script to help deal with the problem of maintaining toolshed >>> tools >>> across multiple toolsheds (eg test and release) >>> >>> The problem I encountered was that switching between test and production >>> versions of a suite of tools can be quite painful because every repository >>> definition like this >>> >>> <repository toolshed="http://toolshed.g2.bx.psu.edu"; >>> name="proteomics_datatypes" owner="iracooke" >>> changeset_revision="463328a6967f"/> >>> >>> needs to be updated to a different toolshed url and (by extension) a >>> different >>> changeset revision. >>> >>> The idea with this script is that you should be able to point it at a >>> directory >>> containing a toolshed repository and it will create a copy of that >>> repository >>> in which the toolshed urls (and changeset revisions) have been updated >>> to correct values for a different toolshed. >>> >>> I'm not sure how others are dealing with this issue (perhaps there is >>> another >>> easier way) .. but I've found this helped me alot so I thought I'd share >>> >>> https://bitbucket.org/iracooke/galaxy_repo_bundler/ >>> >>> Cheers >>> Ira >> >> Thanks Ira, >> >> I've not made as heavy use of inter-repository dependencies as you, but >> thus far I have ignored the problem (only a couple of my repositories are >> affected), in the hope this limitation will be fixed sooner rather than >> later. >> >> Peter > > Thinking out loud, another way to solve this would be to allow multiple > equivalent <repository> entries as a group where any one would be OK. > > e.g. For v0.0.5 of my seq_filter_by_id tool, > > <repository toolshed="http://toolshed.g2.bx.psu.edu"; owner="peterjc" > name="seq_filter_by_id" changeset_revision="abdd608c869b"/> > for http://toolshed.g2.bx.psu.edu/view/peterjc/seq_filter_by_id/abdd608c869b > > or: > > <repository toolshed="http://testtoolshed.g2.bx.psu.edu"; > owner="peterjc" name="seq_filter_by_id" > changeset_revision="66d1ca92fb38"/> > for > http://testtoolshed.g2.bx.psu.edu/view/peterjc/seq_filter_by_id/66d1ca92fb38 > > Something like this maybe?: > > <any_one_of> > <repository toolshed="http://toolshed.g2.bx.psu.edu"; owner="peterjc" > name="seq_filter_by_id" changeset_revision="abdd608c869b"/> > <repository toolshed="http://testtoolshed.g2.bx.psu.edu"; > owner="peterjc" name="seq_filter_by_id" > changeset_revision="66d1ca92fb38"/> > </any_one_of> > > Of course more generally we might also post this on a local public Tool > Shed as well. The point is then the same repository_dependencies.xml > could be used on either tool shed without modification. > > Fixing declaring a dependency on an external Tool Shed would be better - > but perhaps we'll need both or some sort of mirroring federated system > in the long term? > > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ ___________________________________________________________ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
