I cannot guarantee it, but this may be related to a fix I just committed that populates the <repository> tag in the dependency definitions with a toolshed attribute if it is missing (it looks like it is in your case).  I used to not populate the tag, but simply stored the tool shed in the repository metadata.  Bjorn discovered, however, that certain repository installations would not succeed if the toolshed attribute was missing.  WHen I investigated this, I discovered  that some downstream stuff could not locate the appropriate tool shed if the attribute was missing from the tag.

I fixed this in 9836:252027d00b44 by populating this tag attribute if it was missing.  Unfortunately, a new dependency definition has to be uploaded to those repositories that have definitions where it is not set in order to get this fix.  

I don't know if updating your dependency file in this repository will fix this issue, but just wanted to alert you to this.

Very sorry for any inconvenience!

Greg Von Kuster


On May 22, 2013, at 4:26 PM, Peter Cock wrote:

On Mon, May 20, 2013 at 3:05 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
> On Mon, May 20, 2013 at 2:47 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
>> Peter wrote:
>>> Right now the single biggest class of test failures amongst my tools on
>>> the Test Tool Shed is a missing dependencies on the blast_datatypes
>>> repository: http://toolshed.g2.bx.psu.edu/view/devteam/blast_datatypes
>>>
>>> As a short term measure, could the dev team upload blast_datatypes
>>> to the Test Tool Shed as well please (and give me write access)? Then
>>> thanks to the recent change in [1] I can reference the dependency
>>> without explicitly naming the Tool Shed.
>>
>> I've copied the blast_datatypes from the main tool shed to the test
>> tool shed with all history in tact.  See
>>
>> http://testtoolshed.g2.bx.psu.edu/view/devteam/blast_datatypes
>>
>>
>>>
>>> If you can do it in a way that preserves the same revision history can
>>> change set hashes even better - then I can replace this:
>>>
>>> <repository toolshed="http://toolshed.g2.bx.psu.edu"
>>> name="blast_datatypes" owner="devteam"
>>> changeset_revision="f9a7783ed7b6" />
>>>
>>> with:
>>>
>>> <repository name="blast_datatypes" owner="devteam"
>>> changeset_revision="f9a7783ed7b6" />
>>>
>>> and can use the same repository_dependencies.xml file on both Tool
>>> Sheds.
>
> Great, I'm trying that now here:
>
> http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/9ef0d4ecb9d5
> http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/bf634ebee84c
> http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/2d4757de6180

Hi Greg (& Dave),

Thanks for Dave for fixing the missing test results issue,
http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-May/014791.html

I can now see the effect the dependency change had -
unfortunately the blast_datatypes install seems to be
unsuccessful, but I am not seeing a helpful error from
the Tool Shed tests.

Let's focus on the simplest case, where blast_datatypes
is the only dependency:

<?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 name="blast_datatypes" owner="devteam" changeset_revision="f9a7783ed7b6" />
</repositories>

http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/bf634ebee84c

Automated tool test results

Time tested: ~ 6 hours ago
System: Linux 3.5.0-21-generic
Architecture: x86_64
Python version: 2.7.3
Galaxy revision: 9821:feaab01c738a
Galaxy database version: 115
Tool shed revision: 9820:f5fe2f094060
Tool shed database version: 19
Tool shed mercurial version: 2.2.3
Tool shedNameOwnerChangeset revision
testtoolshed.g2.bx.psu.edu blastxml_to_top_descr peterjcbf634ebee84c
Error
None




It seems that an error occurred with the dependencies, but
unfortunately all we get as the error message is "None".

Regards,

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/