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/bf634eb... 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/bf634eb...
Automated tool test results
Tool test results Automated test environment 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 Installation errors - no functional tests were run for any tools in this changeset revision Repository dependencies Tool shed Name Owner Changeset revision testtoolshed.g2.bx.psu.edu blastxml_to_top_descr peterjc bf634ebee84c 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/