Re: [galaxy-dev] Galaxy's dependency on old samtools vs tools wrapping later versions?

2014-11-04 Thread Peter Cock
OK, so this should work then... :)

Thanks Dave,

Peter

On Mon, Nov 3, 2014 at 7:06 PM, Dave Bouvier d...@bx.psu.edu wrote:
 Peter,

 For the automated indexing of bam files, Galaxy uses the samtools version
 linked to as default under tool-dependencies/samtools/

 This should normally be 0.1.19 or older, due to the not-yet-implemented
 handling of bam_index_build and other potential regressions that could be
 uncovered in the future.

--Dave B.


 On 11/03/2014 01:52 PM, Peter Cock wrote:

 Hello all,

 Galaxy currently requires samtools on the $PATH in order to sort
 and index BAM files automatically, and samtools 0.1.19 works fine.

 Unfortunately later versions of samtools index have a regression:
 https://github.com/samtools/samtools/issues/199

 This has caught several people out already,
 e.g. https://biostar.usegalaxy.org/p/7928/
 and https://biostar.usegalaxy.org/p/9335/

 While eventually samtools will be fixed, right now this means we
 can't have samtools 1.1 as the first samtools on the $PATH used
 by Galaxy.

 I am working on a wrapper for samtools bam2fq:
 https://github.com/peterjc/pico_galaxy/tree/master/tools/samtools_bam2fq
 https://testtoolshed.g2.bx.psu.edu/view/peterjc/samtools_bam2fq

 The bam2qf command in samtools 0.1.19 has a number of bugs,
 so I want to target samtools 1.1.  However this has complicated my
 testing since for my BAM input files Galaxy will call samtools index,
 and if it calls samtools 1.1 this will fail.

 I'm not using the tool shed dependencies during development
 so instead came up with the following hack:
 https://github.com/peterjc/picobio/blob/master/sambam/samtools_auto.py

 My question is, what is expected to happen with a Tool Shed installed
 wrapper for samtools 1.1 and Galaxy's attempts to automatically call
 samtools to index any BAM output file? Would the tool environment
 put samtools 1.1 on the (local) $PATH which would then break setting
 the metadata as part of the same job?

 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/


___
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] Galaxy's dependency on old samtools vs tools wrapping later versions?

2014-11-04 Thread Peter Cock
Fingers crossed - perhaps I jumped the gun uploading this to the main
tool shed without seeing the test results on the Test Tool Shed:

https://toolshed.g2.bx.psu.edu/view/peterjc/samtools_bam2fq
https://testtoolshed.g2.bx.psu.edu/view/peterjc/samtools_bam2fq

I look forward to the automated test results from the Tool Sheds ...
http://lists.bx.psu.edu/pipermail/galaxy-dev/2014-November/020792.html

Thanks,

Peter

On Tue, Nov 4, 2014 at 8:38 AM, Peter Cock p.j.a.c...@googlemail.com wrote:
 OK, so this should work then... :)

 Thanks Dave,

 Peter

 On Mon, Nov 3, 2014 at 7:06 PM, Dave Bouvier d...@bx.psu.edu wrote:
 Peter,

 For the automated indexing of bam files, Galaxy uses the samtools version
 linked to as default under tool-dependencies/samtools/

 This should normally be 0.1.19 or older, due to the not-yet-implemented
 handling of bam_index_build and other potential regressions that could be
 uncovered in the future.

--Dave B.


 On 11/03/2014 01:52 PM, Peter Cock wrote:

 Hello all,

 Galaxy currently requires samtools on the $PATH in order to sort
 and index BAM files automatically, and samtools 0.1.19 works fine.

 Unfortunately later versions of samtools index have a regression:
 https://github.com/samtools/samtools/issues/199

 This has caught several people out already,
 e.g. https://biostar.usegalaxy.org/p/7928/
 and https://biostar.usegalaxy.org/p/9335/

 While eventually samtools will be fixed, right now this means we
 can't have samtools 1.1 as the first samtools on the $PATH used
 by Galaxy.

 I am working on a wrapper for samtools bam2fq:
 https://github.com/peterjc/pico_galaxy/tree/master/tools/samtools_bam2fq
 https://testtoolshed.g2.bx.psu.edu/view/peterjc/samtools_bam2fq

 The bam2qf command in samtools 0.1.19 has a number of bugs,
 so I want to target samtools 1.1.  However this has complicated my
 testing since for my BAM input files Galaxy will call samtools index,
 and if it calls samtools 1.1 this will fail.

 I'm not using the tool shed dependencies during development
 so instead came up with the following hack:
 https://github.com/peterjc/picobio/blob/master/sambam/samtools_auto.py

 My question is, what is expected to happen with a Tool Shed installed
 wrapper for samtools 1.1 and Galaxy's attempts to automatically call
 samtools to index any BAM output file? Would the tool environment
 put samtools 1.1 on the (local) $PATH which would then break setting
 the metadata as part of the same job?

 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/


Re: [galaxy-dev] Galaxy's dependency on old samtools vs tools wrapping later versions?

2014-11-03 Thread Dave Bouvier

Peter,

For the automated indexing of bam files, Galaxy uses the samtools 
version linked to as default under tool-dependencies/samtools/


This should normally be 0.1.19 or older, due to the not-yet-implemented 
handling of bam_index_build and other potential regressions that could 
be uncovered in the future.


   --Dave B.

On 11/03/2014 01:52 PM, Peter Cock wrote:

Hello all,

Galaxy currently requires samtools on the $PATH in order to sort
and index BAM files automatically, and samtools 0.1.19 works fine.

Unfortunately later versions of samtools index have a regression:
https://github.com/samtools/samtools/issues/199

This has caught several people out already,
e.g. https://biostar.usegalaxy.org/p/7928/
and https://biostar.usegalaxy.org/p/9335/

While eventually samtools will be fixed, right now this means we
can't have samtools 1.1 as the first samtools on the $PATH used
by Galaxy.

I am working on a wrapper for samtools bam2fq:
https://github.com/peterjc/pico_galaxy/tree/master/tools/samtools_bam2fq
https://testtoolshed.g2.bx.psu.edu/view/peterjc/samtools_bam2fq

The bam2qf command in samtools 0.1.19 has a number of bugs,
so I want to target samtools 1.1.  However this has complicated my
testing since for my BAM input files Galaxy will call samtools index,
and if it calls samtools 1.1 this will fail.

I'm not using the tool shed dependencies during development
so instead came up with the following hack:
https://github.com/peterjc/picobio/blob/master/sambam/samtools_auto.py

My question is, what is expected to happen with a Tool Shed installed
wrapper for samtools 1.1 and Galaxy's attempts to automatically call
samtools to index any BAM output file? Would the tool environment
put samtools 1.1 on the (local) $PATH which would then break setting
the metadata as part of the same job?

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/


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