Cross Tool Shed dependencies / blast_datatypes
Hi Greg, Do you guys have a rough plan for when inter-ToolShed dependencies will be supported? I've been using the Test Tool Shed to validate tools before uploading them to the main Tool Shed - this uncovers things like omitted test files which I don't find locally since I'm testing in-situ. 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. 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. If preserving the hashes isn't possible, I'll use the new [2] 'latest revision' ability instead: <repository name="blast_datatypes" owner="devteam" /> Thanks, Peter -- [1] https://bitbucket.org/galaxy/galaxy-central/commits/842a78530fcd87670198d55d... [2] https://bitbucket.org/galaxy/galaxy-central/commits/35de5a8a928bf63fd5de3d1e...
Hello Peter, Sorry for the delay on this - I was out of the lab last Friday. On May 17, 2013, at 10:16 AM, Peter Cock wrote:
Hi Greg,
Do you guys have a rough plan for when inter-ToolShed dependencies will be supported?
There is a bunch of work to do between now an the GCC to prepare for it. However, the tool shed dependency features have matured to the point that I believe this should not be as difficult to implement as it would have been earlier. I'll try to get this implemented before the GCC.
I've been using the Test Tool Shed to validate tools before uploading them to the main Tool Shed - this uncovers things like omitted test files which I don't find locally since I'm testing in-situ.
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. If preserving the hashes isn't possible, I'll use the new [2] 'latest revision' ability instead:
<repository name="blast_datatypes" owner="devteam" />
Thanks,
Peter
--
[1] https://bitbucket.org/galaxy/galaxy-central/commits/842a78530fcd87670198d55d... [2] https://bitbucket.org/galaxy/galaxy-central/commits/35de5a8a928bf63fd5de3d1e... ___________________________________________________________ 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/
On Mon, May 20, 2013 at 2:47 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hello Peter,
Sorry for the delay on this - I was out of the lab last Friday.
On May 17, 2013, at 10:16 AM, Peter Cock wrote:
Hi Greg,
Do you guys have a rough plan for when inter-ToolShed dependencies will be supported?
There is a bunch of work to do between now an the GCC to prepare for it. However, the tool shed dependency features have matured to the point that I believe this should not be as difficult to implement as it would have been earlier. I'll try to get this implemented before the GCC.
That's fine for me (given the short term fix below).
I've been using the Test Tool Shed to validate tools before uploading them to the main Tool Shed - this uncovers things like omitted test files which I don't find locally since I'm testing in-situ.
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 Thanks, Peter
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<http://testtoolshed.g2.bx.psu.edu/repository/view_repository?status=done&id=90191ce08fa7fc29&message=&changeset_revision=bf634ebee84c> Automated test environment<http://testtoolshed.g2.bx.psu.edu/repository/view_repository?status=done&id=90191ce08fa7fc29&message=&changeset_revision=bf634ebee84c> *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*<http://testtoolshed.g2.bx.psu.edu/repository/view_repository?status=done&id=90191ce08fa7fc29&message=&changeset_revision=bf634ebee84c> Repository dependencies<http://testtoolshed.g2.bx.psu.edu/repository/view_repository?status=done&id=90191ce08fa7fc29&message=&changeset_revision=bf634ebee84c> Tool shedNameOwnerChangeset revisiontesttoolshed.g2.bx.psu.edu blastxml_to_top_descrpeterjcbf634ebee84cErrorNone It seems that an error occurred with the dependencies, but unfortunately all we get as the error message is "None". Regards, Peter
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/
On Wed, May 22, 2013 at 9:59 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
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
Finger's crossed - I've changed repository_dependencies.xml by updating the comment in it, http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/bb81d3afa28d http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/f3a61c2cf309 http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/482b7f4... As an aside, the XML comment line seems not to show up properly in the HTML diff view on the toolshed for this change. For example: Commit message: Uploaded v0.0.20 preview 8, update comment in dependencies XML modified: tools/ncbi_blast_plus/repository_dependencies.xml tools/ncbi_blast_plus/repository_dependencies.xml --- a/tools/ncbi_blast_plus/repository_dependencies.xmlMon May 20 10:04:51 2013 -0400 +++ b/tools/ncbi_blast_plus/repository_dependencies.xmlThu May 23 04:47:28 2013 -0400 @@ -1,5 +1,5 @@ <?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> + +<repository changeset_revision="f9a7783ed7b6" name="blast_datatypes" owner="devteam" toolshed="http://testtoolshed.g2.bx.psu.edu" /> +</repositories> \ No newline at end of file That first "plus" line should give the new comment, i.e. <!-- Revision 4:f9a7783ed7b6 on the main (and test) tool shed is v0.0.14 which added BLAST databases --> Regards, Peter
Hello Peter, On May 23, 2013, at 4:49 AM, Peter Cock wrote:
On Wed, May 22, 2013 at 9:59 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
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
Finger's crossed - I've changed repository_dependencies.xml by updating the comment in it,
http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/bb81d3afa28d http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/f3a61c2cf309 http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/482b7f4...
As an aside, the XML comment line seems not to show up properly in the HTML diff view on the toolshed for this change. For example:
Yes, comments were stripped out and not saved. However, I've committed a fix for this issue in 9844:0acfbcd4235b, so all future comments should be saved. Sorry for the inconvenience of losing any comments you had previously.
Commit message: Uploaded v0.0.20 preview 8, update comment in dependencies XML modified: tools/ncbi_blast_plus/repository_dependencies.xml tools/ncbi_blast_plus/repository_dependencies.xml --- a/tools/ncbi_blast_plus/repository_dependencies.xmlMon May 20 10:04:51 2013 -0400 +++ b/tools/ncbi_blast_plus/repository_dependencies.xmlThu May 23 04:47:28 2013 -0400 @@ -1,5 +1,5 @@ <?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> + +<repository changeset_revision="f9a7783ed7b6" name="blast_datatypes" owner="devteam" toolshed="http://testtoolshed.g2.bx.psu.edu" /> +</repositories> \ No newline at end of file
That first "plus" line should give the new comment, i.e.
<!-- Revision 4:f9a7783ed7b6 on the main (and test) tool shed is v0.0.14 which added BLAST databases -->
Regards,
Peter
On Thu, May 23, 2013 at 4:58 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hello Peter,
On May 23, 2013, at 4:49 AM, Peter Cock wrote:
On Wed, May 22, 2013 at 9:59 PM, Greg Von Kuster <greg@bx.psu.edu> wrote: As an aside, the XML comment line seems not to show up properly in the HTML diff view on the toolshed for this change. For example:
Yes, comments were stripped out and not saved.
I see what you mean now, the diff was actually 'correct' - my old comment line had been removed and replaced with a blank line.
However, I've committed a fix for this issue in 9844:0acfbcd4235b, so all future comments should be saved. Sorry for the inconvenience of losing any comments you had previously.
Great - I doubt anyone would be too bothered about the missing comments except perhaps where it indicated that a feature was being worked on but wasn't yet available. Thanks, Peter
On Wed, May 22, 2013 at 9:26 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Mon, May 20, 2013 at 3:05 PM, Peter Cock wrote:
On Mon, May 20, 2013 at 2:47 PM, Greg Von Kuster wrote:
Peter wrote: 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
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.
Hi Greg, Something is still amiss with this dependency and/or the Tool Shed display. These two are currently listed under "Latest revision: installation errors" but don't show any errors or test failures: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/482b7f4... http://testtoolshed.g2.bx.psu.edu/view/peterjc/clinod/c4f503750a44 On other hand, this third tool with the blast_datatypes dependency http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/f3a61c2cf309 fails with a known issue: https://trello.com/card/-/506338ce32ae458f6d15e4b3/801 I'm not seeing any similar issue with the ncbi_blast_plus suite: http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/bb81d3afa28d Regards, Peter
On Fri, May 24, 2013 at 11:18 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi Greg,
Something is still amiss with this dependency and/or the Tool Shed display. These two are currently listed under "Latest revision: installation errors" but don't show any errors or test failures:
http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/482b7f4...
http://testtoolshed.g2.bx.psu.edu/view/peterjc/clinod/c4f503750a44
...
Correction - clinod doesn't depend on blast_datatypes so whatever is going wrong is likely a more general tool installation failure. Peter
Peter, The issue was the same as before, an earlier repository in the list took longer than 1800 seconds to compile tool dependencies, so the testing framework canceled the install and test process. I've added that repository to the exclude list, and implemented a framework to install and test a single repository in the same environment as is used for the nightly test runs. I have also run that framework on the clinod repository, and you should now see relevant test results. --Dave B. On 5/24/13 06:21:01.000, Peter Cock wrote:
On Fri, May 24, 2013 at 11:18 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi Greg,
Something is still amiss with this dependency and/or the Tool Shed display. These two are currently listed under "Latest revision: installation errors" but don't show any errors or test failures:
http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/482b7f4...
http://testtoolshed.g2.bx.psu.edu/view/peterjc/clinod/c4f503750a44
...
Correction - clinod doesn't depend on blast_datatypes so whatever is going wrong is likely a more general tool installation failure.
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/
On Fri, May 24, 2013 at 4:58 PM, Dave Bouvier <dave@bx.psu.edu> wrote:
Peter,
The issue was the same as before, an earlier repository in the list took longer than 1800 seconds to compile tool dependencies, so the testing framework canceled the install and test process. I've added that repository to the exclude list, and implemented a framework to install and test a single repository in the same environment as is used for the nightly test runs. I have also run that framework on the clinod repository, and you should now see relevant test results.
--Dave B.
Thanks Dave - more isolation between the testing of each repository sounds wise. The good news is I got a useful error from clinod over night which I hope to have fixed (it seems your cluster nodes only have 4 cores and the tool refused to run when I told it to use 8 threads). The bad news is I still don't see any test error or install error from this repository using the blast_datatypes dependency - does this need its tests to be manually rerun (e.g. I could upload a dummy change)?: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr/482b7f4... As noted before, my other tools using the blast_datatypes dependency are giving useful error messages: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/f3a61c2cf309 http://testtoolshed.g2.bx.psu.edu/view/peterjc/ncbi_blast_plus/bb81d3afa28d Regards, Peter
participants (3)
-
Dave Bouvier -
Greg Von Kuster -
Peter Cock