Hi Peter,

As you discovered, repository dependency definitions are currently supported 
within a single tool shed.  This is a temporary restriction, however, and is 
simply due to time / resource constraints.  The following section of the tool 
shed wiki communicates this.

http://wiki.galaxyproject.org/DefiningRepositoryDependencies

Repository dependencies: defining additional required repositories and 
repository contents

Repositories in the tool shed can contain a file named 
repository_dependencies.xml that defines dependency relationships between 
repositories.  Repository dependency definitions are currently supported only 
within the same tool shed.  In other words, a repository in a local tool shed 
cannot require a repository in the main Galaxy tool shed.  Support for 
repository dependencies across tool sheds will be available some time in the 
future. 

Greg Von Kuster


On Feb 22, 2013, at 9:23 AM, Peter Cock wrote:

> Hi all,
> 
> I've just hit what I consider to be a bug, but may be a design
> choice which I don't yet understand: It appears that repository
> dependencies cannot refer to other Tool Sheds.
> 
> As an example, I want to explore some more complicated
> dependency work in my Blast2GO wrapper (I'd like it to be
> able to download the underlying Java tool automatically).
> I therefore started by uploading the previous releases to the
> Test Tool Shed,
> 
> http://toolshed.g2.bx.psu.edu/view/peterjc/blast2go -->
> http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go -->
> 
> The Blast2GO wrapper requires the 'blastxml' format, which
> is declared via a repository_dependencies.xml file as follows:
> 
> <?xml version="1.0"?>
> <repositories description="This requires the BLAST datatype
> definitions (e.g. the BLAST XML format).">
> <!-- Revision 4:f9a7783ed7b6 on the main tool shed is v0.0.14 which
> added BLAST databases -->
> <repository toolshed="http://toolshed.g2.bx.psu.edu";
> name="blast_datatypes" owner="devteam"
> changeset_revision="f9a7783ed7b6" />
> </repositories>
> 
> Unfortunately, uploading versions of the Blast2GO wrapper with
> this definition (which points at the main tool shed) to the test
> tool shed results in this error message:
> 
> repository_dependencies.xml - Repository dependencies are currently
> supported only within the same tool shed. Ignoring repository
> dependency definition for tool shed http://toolshed.g2.bx.psu.edu,
> name blast_datatypes, owner devteam, changeset revision f9a7783ed7b6.
> 
> Given the idea of an ecosystem of Tool Sheds, with some
> groups maintaining their own local Tool Shed and perhaps
> publishing tools there, it seems likely we will need to be
> able to define dependencies on other tool sheds - and in
> particularly the main tool shed at Penn State which I see
> having a hub-like role. But right now, that doesn't work.
> 
> Is this a short term limitation (since cross-Tool Shed
> dependencies are bound to be more complex to support),
> or a deliberate policy?
> 
> Thanks,
> 
> 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/

___________________________________________________________
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/

Reply via email to