Re: https://github.com/nf-core/covid19 - nextflow pipeline
On 25.03.20 11:36, Andreas Tille wrote:
[@Charles, please read below]
Hi Steffen,
On Tue, Mar 24, 2020 at 11:07:38PM +0100, Steffen Möller wrote:
Wrt package lists I know you need this for the blends structure.
Well, not for the structure. We need to mention packaging tasks
and links to useful software could be put on our todo list. The
tool I currently prefer is the blends structure (until we have
something more practical).
A single package is neat to see packaged, but we need to complete a
workflow and test that workflow intensively. I suggest we agree on a set
of workflows we want to bring to Debian and then we do that. Non-free,
experimental, preferably main - but Debian, in a way that official
images of docker/amazon can find and install it.
I don't
have these lists, What I have is a small list of lists:
https://github.com/nanoporetech/ - the nanopore is a prime tool for
covid-19
Hmmm, that github directory lists several tools but none with this
description neither the name nanopore. I've found a software named
nanopore on Github here:
https://github.com/mitenjain/nanopore
Which one do you mean?
The is the official repository of the creator of the Nanopore. I want
them all, but we should start with the easy ones and the ones and the
ones required from workflows the we decide to bring to Debian.
I just looked at is
https://github.com/nanoporetech/qcat/blob/master/Dockerfile . This
starts with an Ubuntu image and compiles the package on the fly. Conda
is not mentioned in that repository but is has it
https://anaconda.org/bioconda/qcat . My preferred package name would be
nanoporetech-qcat .
https://github.com/nf-core
That's also a directory. I've got a previous hint to
https://salsa.debian.org/med-team/chip-seq
which is close to ready for uploading (should be listed on the covid-19
task soon). What else besided chip-seq would be most relevant.
I suggest we take the workflow of interest, say
https://github.com/nf-core/epitopeprediction/blob/master/environment.yml
and look at the packages loaded from Conda. For the epitope prediction
this is
- python=2.7.15 #dont upgrade, FRED2 needs python 2.7 for now
- multiqc=1.6 #cant upgrade due to Python2 fix
- snpsift=4.3.1t
- csvtk=0.19.1
- fred2=2.0.5
- mhcflurry=1.4.3
- mhcnuggets=2.3.2
- conda-forge::r-markdown=1.1
Seems like we need to give FRED2 a bit of a technical push. And that is
exactly how Debian is helping.
I am not sure about the amont of energy I want to continue to invest
into bcbio at the very moment, I must admit.
https://salsa.debian.org/med-team/bcbio/-/blob/master/debian/TODO
I'll re-check your list.
Postpone that until the package is found relevant also for another workflow.
and there is another RNAseq library that is _almost_ there, i.e. we have
all the packages, but
https://salsa.debian.org/med-team/pigx-rnaseq/-/blob/master/debian/TODO
describes issues about getting the css files into the R packages to have
nicer reports, without which the tests of pigx-rnaseq fail.
I can have a look. It needs multiqc which in turn has a non-free
dependency[1]. I might try to follow the hint that we simply drop
Highcharts and document in README.Debian that the functionality is
restricted. This might help the dependencies of multiqc. What do you
think about this?
I have kept referencing the online repositories of the JavaScript
library, i.e. I introduced a privacy violation. The package may then go
to non-free or so but I am fine with that - biology first. For me. And
bcbio already is in contrib because of a dependency on vienna-rna (which
is one of those "almost free" licenses).
Also, this
runs into the missing bits of the popular r-cran-locfit package.
Charles, are you reading here? We really need to push this issue
forward.
This happens in deseq2.
[1] https://github.com/ewels/MultiQC/issues/800
It is not on me to decide what workflow should be followed up. I suggest
to collect a series of options and the community should somehow
distribute the work.
Steffen
Reply to: