[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any volunter to write a test for bamclipper?



Am 25.03.21 um 22:00 schrieb Nilesh Patra:
> On 2021-03-26 01:58, Andreas Tille wrote:
>> Hi folks,
>>
>> I have packaged bamclipper[1] since it is a precondition for the
>> pipeline covpipe[2] which is developed and used in my institute.
>> (@Steffen, possibly another column in the spreadsheet.)
Please add it.
>> Despite bamclipper is pretty easy I would love to have some autopkgtest
>> but I'm lacking the needed files (bam + bam.bai as well as bedpe).  The
>> README.md[3] has an example that could be used as autopkgtest - so it
>> should not be a hard job for someone who has such files / knows how to
>> find some examples.
> I found those files here[1] inside examples/ dir -- it also has
> outputted *.primer.bam* files, so I think it is sensible
> to assume that these files work.
> I follow this in other packages as well, when on adding certain bam or
> sam files, "something" happens which is good for
> at least a preliminary functioning test :-)
>
> I added a autopkgtest to the salsa repo, please take in a look.
>
> PS: Please consider enabling salsa CI for any new packages that you
> might push. I did so for this one for now.
>
> [1]: https://github.com/tommyau/bamclipper

https://software.broadinstitute.org/software/igv/BAM

One of the many reads from a high-throughput sequencing machine
(pre-Nanopore this was 30, 70 or 144 nucleotides in length, since the
nanopore we are talking about 10^6 "basepairs" that are continuously
sequenced) is just a series of characters. For every such read you want
to know where in the reference genome it likely was sequenced from, how
the quality was at different parts of the read and how well it matches
against a reference genome.

bowtie http://bowtie-bio.sourceforge.net/manual.shtml gets reads as
input, writes SAM which are converted to BAM via "samtools view".

There is loads of public data out there that we could use for testing
purposes. As long as we can automate the generation of such a Debian Med
Testing Environment from public data - there is no need to have
everything that we test on as a Debian package, right?

Best,

Steffen




Reply to: