[galaxy-dev] Looking for brave testers. New barcode splitter outputing splitted datasets directly to the history.

[Carlos Borroto]

Hi,

I was wondering if I could get someone to test this new barcode
splitter I wrote. The main reason for me to duplicate the already
great fastx-toolkit based splitter, is so I can use galaxy's multiple
output capabilities.

You can find this tool in the testtoolshed for now(after some more
testing I will moved to the main toolshed):
http://testtoolshed.g2.bx.psu.edu/view/cjav/split_by_barcode

Hopefully I got Galaxy's tool dependency system right(it works on my
box, not that this says much) and installing this tool should be quite
easy.

I have to say big thanks to Biopython and this[1] anonymous soul for
making it quite easy to write the actual code doing the heavy lifting.

[1]https://gist.github.com/dgrtwo/3725741

Cheers,
Carlos
___
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/

Re: [galaxy-dev] Display BAM and bigWig on UCSC when require_login = False

[Philippe Veber]

Dear all,

We experienced the same issue. In the current state, either we can't
display the data using a genome browser, either we have to grant anonymous
access. Was it considered a concern that datasets may be accessed without a
login? If so, may I suggest to add an option so that we permit the download
of datasets without login (they are still protected by the digest) without
allowing anonymous access?

Cheers,
  Philippe.



2013/7/29 Federico Zambelli 

> Dear all,
>
> I'm running a local version of Galaxy using nginx as proxy and I have
> problems with the visualization of remote tracks (like .bam or .bigwig) on
> the UCSC genome browser. If I disable the anonymous login and then try to
> display a .bam or .bigwig file on UCSC genome browser I get this error:
>
> redirected to non-http(s): /galaxy/root
>
> If anonymous login is enabled then the track visualization works fine.
> Any suggestions?
>
> Thank you,
> F.
>
>
> --
> ==**==
> Federico Zambelli, Ph.D.
> Bioinformatics, Evolution and Comparative Genomics Lab
> Dept. of Biosciences
> University of Milano - Italy
>
> What can be asserted without proof can be dismissed without proof.
> ==**==
> __**_
> 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/

[galaxy-dev] workflow_execute.py failing!

[Hakeem Almabrazi]

Hi,

I have been trying to use workflow_execute.pl to execute a workflow that has 
~50 steps.  I keep getting this error after running for few seconds knowing I 
could run the same workflow from the GUI without any issue.

HTTP Error 500: Internal Server Error
500 Internal Server Error
The server has either erred or is incapable of performing
the requested operation.
*
And here is some error I capture in the log file>

  File "/usr/local/galaxy/galaxy-dist/lib/galaxy/tools/__init__.py", line 2126, 
in execute
return self.tool_action.execute( self, trans, incoming=incoming, 
set_output_hid=set_output_hid, history=history, **kwargs )
  File "/usr/local/galaxy/galaxy-dist/lib/galaxy/tools/actions/__init__.py", 
line 362, in execute
history.add_dataset( data, set_hid = set_output_hid )
  File "/usr/local/galaxy/galaxy-dist/lib/galaxy/web/framework/__init__.py", 
line 1124, in __getattr__
if key not in self: raise AttributeError, key
AttributeError: add_dataset

Looking at the created history the first 14 steps get scheduled and executed.  
But nothing else.  Meaning the rest of the steps get omitted.  This could be 
due to the script get crashed before it complete registering the rest of the 
steps of the workflow.

Does anyone has any idea what could be going on here?

Best regards.






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

Re: [galaxy-dev] API question: is it possible to start exporting histories

[Jeremy Goecks]

> Is it currently possible to export histories via the API?

Not possible yet but is definitely something we'd like to implement and/or see 
from a community contribution.

Best,
J.
___
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/

[galaxy-dev] options from_dataset evaluation in workflow

[Wolfgang Maier]

Dear all,
in one of my tools I'm populating a list of possible
choices from a file in the history using the  tag.
Now using the tool as part of a workflow, the choices are
not calculated at the setup stage, but I have to enter
free-text and Galaxy seems to evaluate whether that's a
legal choice only when the specific tool starts running
(way down in my workflow). Is there any workaround for this
behavior, so that choices are presented before workflow
execution?
Thanks for any help,
Wolfgang
___
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/

Re: [galaxy-dev] Lost in tool dependencies

[Bjoern Gruening]

Hi,

> Moving the dependencies to tool_dependencies.xml worked as a charm. 
> Thanks for your help!

Great!

> I tested the infernal package, and it worked as well! However, the 
> package_infernal_1_1rc4, owned by the iuc, is enough for my purpose and 
> already on the main tool shed, so no need to push the infernal wrapper 
> as well if you're not willing to.

It is still work in progress to I will wait for it and try to get some
testers. As soon as infernal 1.1 final will be out I try to update
package_infernal_1_1rc4. Good to know that it is actually used :)

Ciao,
Bjoern

> Cheers,
> 
> Lionel
> 
> On 09/05/2013 10:45 PM, Björn Grüning wrote:
> > Hi Lionel!
> >
> >> Hi Björn,
> >>
> >>> There is a version in the testtoolshed, I can migrate it if you like and
> >>> if you can confirm that you can install it :)
> >>
> >> I'd be very interested in the infernal wrapper! I'll try to install it.
> >
> > Hope you like it!
> >
> >>> The problem is that you do not have defined your tools in the
> >>> tool_dependencies.xml file. Galaxy will search in that file (with the
> >>> keys specified in your tool.xml) and create the path to your repository.
> >>>
> >>> Try the attached xml file and delete your repository.xml file.
> >>
> >> Alright, I'll try that tomorrow. But I'm not sure I grasp the difference 
> >> between the tool_dependencies.xml and the repository_dependencies.xml file 
> >> then. I used to put my dependencies in tool_dependencies.xml but looking 
> >> for the definition of it I stumbled upon this page:
> >> http://wiki.galaxyproject.org/DefiningRepositoryDependencies
> >> and thought that it was appropriate in my case. Apparently not...
> >
> > Think of it like repository dependencies and not tool dependencies. For
> > example datatypes are not really a tool dependency, but our repository
> > needs it. These will go to repository_dependencies.xml.
> >
> > http://toolshed.g2.bx.psu.edu/view/bgruening/silicos_it
> >
> > An other example are meta-repositories, its a repository with links to
> > other repos, that is also defined in repository_depedencies.xml
> >
> > http://toolshed.g2.bx.psu.edu/view/bgruening/chemicaltoolbox
> >
> > Everything that your tool needs for building the path, must go to the
> > tool dependencies.
> >
> >> Thanks for your help!
> >
> > No problem!
> > Salve,
> > Bjoern
> >
> >> Lionel
> >>
> >> On 5 Sep 2013, at 17:22 , Bjoern Gruening  
> >> wrote:
> >>
> >>> Hi Lionel,
> >>>
>  Bjoern and others,
> 
>  I'm back at that. I published my tool on the toolshed
>  (http://toolshed.g2.bx.psu.edu/view/lionelguy/prokka). I created a new,
>  fresh instance of galaxy from scratch, with a new database. I went on
>  and installed prokka from the toolshed. Prokka has a lot of
>  dependencies, that are handled through a repository_dependencies.xml 
>  file:
> 
>  
>  
> http://toolshed.g2.bx.psu.edu";
>  name="trna_prediction" owner="bgruening"
>  changeset_revision="d34f31cbc9dd" />
> http://toolshed.g2.bx.psu.edu"; name="barrnap"
>  owner="simon-gladman" changeset_revision="a41418a3bd38" />
> http://toolshed.g2.bx.psu.edu"; name="prodigal"
>  owner="edward-kirton" changeset_revision="304c1a67bb7b" />
> 
> >>>
> >>> There is a version in the testtoolshed, I can migrate it if you like and
> >>> if you can confirm that you can install it :)
> >>>
> >>> http://testtoolshed.g2.bx.psu.edu/view/iuc/package_infernal_1_1rc4
> >>>
> http://toolshed.g2.bx.psu.edu";
>  name="package_hmmer_3_1" owner="lionelguy"
>  changeset_revision="007c736bf7e8" />
> http://toolshed.g2.bx.psu.edu";
>  name="ncbi_blast_plus" owner="devteam" changeset_revision="9dabbfd73c8a" 
>  />
>  
> 
>  The installation went well, and all depencencies show as installed in my
>  admin panel. Only biopython and numpy (dependencies from
>  trna_prediction) miss some dependencies, but are installed anyway.
> 
>  The requirements are stated in my prokka.xml file:
> 
> 
>   prokka
>   aragorn
>   prodigal
>   barrnap
>   hmmer
>   blast+
>   tbl2asn
> 
> 
>  When I run prokka, though, all dependency resolution fail, except the
>  prokka one (the package itself):
> 
>  galaxy.tools DEBUG 2013-09-05 16:33:03,045 Building dependency shell
>  command for dependency 'prokka'
>  galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell
>  command for dependency 'aragorn'
>  galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve
>  dependency on 'aragorn', ignoring
>  galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell
>  command for dependency 'prodigal'
>  galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve
>  dependency on 'prodigal', ignoring
>  galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependen

Re: [galaxy-dev] Lost in tool dependencies

[Lionel Guy]

Hi Björn,

Moving the dependencies to tool_dependencies.xml worked as a charm. 
Thanks for your help!


I tested the infernal package, and it worked as well! However, the 
package_infernal_1_1rc4, owned by the iuc, is enough for my purpose and 
already on the main tool shed, so no need to push the infernal wrapper 
as well if you're not willing to.


Cheers,

Lionel

On 09/05/2013 10:45 PM, Björn Grüning wrote:

Hi Lionel!


Hi Björn,


There is a version in the testtoolshed, I can migrate it if you like and
if you can confirm that you can install it :)


I'd be very interested in the infernal wrapper! I'll try to install it.


Hope you like it!


The problem is that you do not have defined your tools in the
tool_dependencies.xml file. Galaxy will search in that file (with the
keys specified in your tool.xml) and create the path to your repository.

Try the attached xml file and delete your repository.xml file.


Alright, I'll try that tomorrow. But I'm not sure I grasp the difference 
between the tool_dependencies.xml and the repository_dependencies.xml file 
then. I used to put my dependencies in tool_dependencies.xml but looking for 
the definition of it I stumbled upon this page:
http://wiki.galaxyproject.org/DefiningRepositoryDependencies
and thought that it was appropriate in my case. Apparently not...


Think of it like repository dependencies and not tool dependencies. For
example datatypes are not really a tool dependency, but our repository
needs it. These will go to repository_dependencies.xml.

http://toolshed.g2.bx.psu.edu/view/bgruening/silicos_it

An other example are meta-repositories, its a repository with links to
other repos, that is also defined in repository_depedencies.xml

http://toolshed.g2.bx.psu.edu/view/bgruening/chemicaltoolbox

Everything that your tool needs for building the path, must go to the
tool dependencies.


Thanks for your help!


No problem!
Salve,
Bjoern


Lionel

On 5 Sep 2013, at 17:22 , Bjoern Gruening  wrote:


Hi Lionel,


Bjoern and others,

I'm back at that. I published my tool on the toolshed
(http://toolshed.g2.bx.psu.edu/view/lionelguy/prokka). I created a new,
fresh instance of galaxy from scratch, with a new database. I went on
and installed prokka from the toolshed. Prokka has a lot of
dependencies, that are handled through a repository_dependencies.xml file:



   http://toolshed.g2.bx.psu.edu";
name="trna_prediction" owner="bgruening"
changeset_revision="d34f31cbc9dd" />
   http://toolshed.g2.bx.psu.edu"; name="barrnap"
owner="simon-gladman" changeset_revision="a41418a3bd38" />
   http://toolshed.g2.bx.psu.edu"; name="prodigal"
owner="edward-kirton" changeset_revision="304c1a67bb7b" />
   


There is a version in the testtoolshed, I can migrate it if you like and
if you can confirm that you can install it :)

http://testtoolshed.g2.bx.psu.edu/view/iuc/package_infernal_1_1rc4


   http://toolshed.g2.bx.psu.edu";
name="package_hmmer_3_1" owner="lionelguy"
changeset_revision="007c736bf7e8" />
   http://toolshed.g2.bx.psu.edu";
name="ncbi_blast_plus" owner="devteam" changeset_revision="9dabbfd73c8a" />


The installation went well, and all depencencies show as installed in my
admin panel. Only biopython and numpy (dependencies from
trna_prediction) miss some dependencies, but are installed anyway.

The requirements are stated in my prokka.xml file:

   
 prokka
 aragorn
 prodigal
 barrnap
 hmmer
 blast+
 tbl2asn
   

When I run prokka, though, all dependency resolution fail, except the
prokka one (the package itself):

galaxy.tools DEBUG 2013-09-05 16:33:03,045 Building dependency shell
command for dependency 'prokka'
galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell
command for dependency 'aragorn'
galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve
dependency on 'aragorn', ignoring
galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell
command for dependency 'prodigal'
galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve
dependency on 'prodigal', ignoring
galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell
command for dependency 'barrnap'
galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve
dependency on 'barrnap', ignoring
galaxy.tools DEBUG 2013-09-05 16:33:03,049 Building dependency shell
command for dependency 'hmmer'
galaxy.tools WARNING 2013-09-05 16:33:03,049 Failed to resolve
dependency on 'hmmer', ignoring
galaxy.tools DEBUG 2013-09-05 16:33:03,049 Building dependency shell
command for dependency 'blast+'
galaxy.tools WARNING 2013-09-05 16:33:03,049 Failed to resolve
dependency on 'blast+', ignoring
galaxy.tools DEBUG 2013-09-05 16:33:03,049 Building dependency shell
command for dependency 'tbl2asn'
galaxy.tools WARNING 2013-09-05 16:33:03,049 Failed to resolve
dependency on 'tbl2asn', ignoring

The run actually succeeds, because those tools are installed elsewhere
in my system, but I can see that prokka is not using the installed
versi

[galaxy-dev] API question: is it possible to start exporting histories

[Joachim Jacob | VIB |]

Hi all,

Is it currently possible to export histories via the API? I have one 
user who want to download and store her data. Total sizes of all her 
histories combined is about ~700GB.


I think this is a typical API job: to list all her histories, start 
'exporting to file' all of them, and finally download all exported 
histories to a disk. But looking at the current API code, I doubt 
whether this can be done. Hence my question.



Cheers,
Joachim

--
Joachim Jacob
Contact details: http://www.bits.vib.be/index.php/about/80-team


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

Re: [galaxy-dev] Solved Tool's toolshed page does not get updated after uploading new version

[Joachim Jacob | VIB |]

Hmm, now the tool's page is updated. Problem solved. Perhaps a browser 
cache issue or something alike.


Joachim Jacob
Contact details: http://www.bits.vib.be/index.php/about/80-team


On 09/06/2013 10:22 AM, Joachim Jacob | VIB | wrote:

Hi all,

My issue: I have put a new version of a tool in our local toolshed 
(via 'hg push'). Now, going to the tool's page, still the old version 
of the README is displayed. When browsing the repository, the new 
(last uploaded) version is there. In addition, the tool's page show 
the latest revision, but displays the former version.


Did I go wrong somewhere or is this a bug?

[ I don't know whether this is known already - Trello is annoyingly 
slow, and there is no easy way to swiftly search in the non-existing 
Trello list Toolshed ( sorry, bear with me please, I needed to point 
out my issues with Trello at least once  ;-) ]



Thanks,
Joachim



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

[galaxy-dev] Tool's toolshed page does not get updated after uploading new version

[Joachim Jacob | VIB |]

Hi all,

My issue: I have put a new version of a tool in our local toolshed (via 
'hg push'). Now, going to the tool's page, still the old version of the 
README is displayed. When browsing the repository, the new (last 
uploaded) version is there. In addition, the tool's page show the latest 
revision, but displays the former version.


Did I go wrong somewhere or is this a bug?

[ I don't know whether this is known already - Trello is annoyingly 
slow, and there is no easy way to swiftly search in the non-existing 
Trello list Toolshed ( sorry, bear with me please, I needed to point out 
my issues with Trello at least once  ;-) ]



Thanks,
Joachim

--
Joachim Jacob
Contact details: http://www.bits.vib.be/index.php/about/80-team


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

Re: [galaxy-dev] Lost in tool dependencies

[Björn Grüning]

Hi Lionel!

> Hi Björn, 
> 
> > There is a version in the testtoolshed, I can migrate it if you like and
> > if you can confirm that you can install it :)
> 
> I'd be very interested in the infernal wrapper! I'll try to install it.

Hope you like it!

> > The problem is that you do not have defined your tools in the
> > tool_dependencies.xml file. Galaxy will search in that file (with the
> > keys specified in your tool.xml) and create the path to your repository.
> > 
> > Try the attached xml file and delete your repository.xml file.
> 
> Alright, I'll try that tomorrow. But I'm not sure I grasp the difference 
> between the tool_dependencies.xml and the repository_dependencies.xml file 
> then. I used to put my dependencies in tool_dependencies.xml but looking for 
> the definition of it I stumbled upon this page:
> http://wiki.galaxyproject.org/DefiningRepositoryDependencies
> and thought that it was appropriate in my case. Apparently not...

Think of it like repository dependencies and not tool dependencies. For
example datatypes are not really a tool dependency, but our repository
needs it. These will go to repository_dependencies.xml. 

http://toolshed.g2.bx.psu.edu/view/bgruening/silicos_it

An other example are meta-repositories, its a repository with links to
other repos, that is also defined in repository_depedencies.xml

http://toolshed.g2.bx.psu.edu/view/bgruening/chemicaltoolbox

Everything that your tool needs for building the path, must go to the
tool dependencies.

> Thanks for your help!

No problem!
Salve,
Bjoern

> Lionel
> 
> On 5 Sep 2013, at 17:22 , Bjoern Gruening  wrote:
> 
> > Hi Lionel,
> > 
> >> Bjoern and others,
> >> 
> >> I'm back at that. I published my tool on the toolshed 
> >> (http://toolshed.g2.bx.psu.edu/view/lionelguy/prokka). I created a new, 
> >> fresh instance of galaxy from scratch, with a new database. I went on 
> >> and installed prokka from the toolshed. Prokka has a lot of 
> >> dependencies, that are handled through a repository_dependencies.xml file:
> >> 
> >> 
> >> 
> >>   http://toolshed.g2.bx.psu.edu"; 
> >> name="trna_prediction" owner="bgruening" 
> >> changeset_revision="d34f31cbc9dd" />
> >>   http://toolshed.g2.bx.psu.edu"; name="barrnap" 
> >> owner="simon-gladman" changeset_revision="a41418a3bd38" />
> >>   http://toolshed.g2.bx.psu.edu"; name="prodigal" 
> >> owner="edward-kirton" changeset_revision="304c1a67bb7b" />
> >>   
> > 
> > There is a version in the testtoolshed, I can migrate it if you like and
> > if you can confirm that you can install it :)
> > 
> > http://testtoolshed.g2.bx.psu.edu/view/iuc/package_infernal_1_1rc4 
> > 
> >>   http://toolshed.g2.bx.psu.edu"; 
> >> name="package_hmmer_3_1" owner="lionelguy" 
> >> changeset_revision="007c736bf7e8" />
> >>   http://toolshed.g2.bx.psu.edu"; 
> >> name="ncbi_blast_plus" owner="devteam" changeset_revision="9dabbfd73c8a" />
> >> 
> >> 
> >> The installation went well, and all depencencies show as installed in my 
> >> admin panel. Only biopython and numpy (dependencies from 
> >> trna_prediction) miss some dependencies, but are installed anyway.
> >> 
> >> The requirements are stated in my prokka.xml file:
> >> 
> >>   
> >> prokka
> >> aragorn
> >> prodigal
> >> barrnap
> >> hmmer
> >> blast+
> >> tbl2asn
> >>   
> >> 
> >> When I run prokka, though, all dependency resolution fail, except the 
> >> prokka one (the package itself):
> >> 
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,045 Building dependency shell 
> >> command for dependency 'prokka'
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell 
> >> command for dependency 'aragorn'
> >> galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve 
> >> dependency on 'aragorn', ignoring
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell 
> >> command for dependency 'prodigal'
> >> galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve 
> >> dependency on 'prodigal', ignoring
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,048 Building dependency shell 
> >> command for dependency 'barrnap'
> >> galaxy.tools WARNING 2013-09-05 16:33:03,048 Failed to resolve 
> >> dependency on 'barrnap', ignoring
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,049 Building dependency shell 
> >> command for dependency 'hmmer'
> >> galaxy.tools WARNING 2013-09-05 16:33:03,049 Failed to resolve 
> >> dependency on 'hmmer', ignoring
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,049 Building dependency shell 
> >> command for dependency 'blast+'
> >> galaxy.tools WARNING 2013-09-05 16:33:03,049 Failed to resolve 
> >> dependency on 'blast+', ignoring
> >> galaxy.tools DEBUG 2013-09-05 16:33:03,049 Building dependency shell 
> >> command for dependency 'tbl2asn'
> >> galaxy.tools WARNING 2013-09-05 16:33:03,049 Failed to resolve 
> >> dependency on 'tbl2asn', ignoring
> >> 
> >> The run actually succeeds, because those tools are installed elsewhere 
> >> in my system, but I can see th