Hi Bjoern, It's good to know I'm not the only one to encounter this. I think it tends to bite when you have alot of dependencies.
I use the same method as you (uploading one repo .. then another and so on) ... using the script each time to automate the upload. BTW I made a little addition to the script today so it automatically commits and checks in the changes via mercurial ... that makes the workflow really quite smooth. Your suggestion of possibly allowing the revision tag to be blank makes alot of sense ... it could simply imply (always use the latest available). That would certainly make things much much easier for those who aren't using a script. Cheers Ira On 07/05/2013, at 7:49 PM, Björn Grüning <bjoern.gruen...@pharmazie.uni-freiburg.de> wrote: > Hi, > > nice work Ira! That problem also bothers me. I have written a similar > script in python, but its not documented ;) I really think a more > advanced solution like Peter's are needed midterm. > > To fix the revision problems: What about leaving the revision tag blank > means that the toolshed should insert the latest revision of a tool > dependency during upload. > > For me the vast majority of repo uploads referring to the latest > dependencies of other repo's. So I ending up with uploading one repo, > running my script to insert the new revision tag, uploading the second, > rerun the script and so on ... > > Ciao, > Bjoern > >> 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/ > > > ___________________________________________________________ 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/
