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

Re: Bug#783833: ITP: python-obitools -- set of programs specifically designed for analyzing NGS data in a DNA metabarcoding contex



On Thu, 30 Apr 2015 16:23:36 +0000
olivier sallou <olivier.sallou@gmail.com> wrote:

> Le jeu. 30 avr. 2015 à 17:42, Scott Kitterman <debian@kitterman.com> a
> écrit :
> 
> > On Thursday, April 30, 2015 05:13:03 PM Olivier Sallou wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Olivier Sallou <osallou@debian.org>
> > >
> > > * Package name    : python-obitools
> > >   Version         : 1.1.16
> > >   Upstream Author : Eric Coissac
> > > * URL             : http://metabarcoding.org//obitools/
> > > * License         : CeCILL-V2
> > >   Programming Lang: Python
> > >   Description     : set of programs specifically designed for
> > > analyzing
> > NGS
> > > data in a DNA metabarcoding contex
> > >
> > > The OBITools package is a set of programs specifically designed
> > > for analyzing NGS data in a DNA metabarcoding context, taking
> > > into account taxonomic information. OBITools enrich the Unix
> > > command line interface
> > with
> > > a set of new commands dedicated to NGS data processing. Most of
> > > them
> > have a
> > > name starting with the obi prefix. They automatically recognize
> > > the input file format amongst most of the standard sequence file
> > > formats (i.e.
> > fasta,
> > > fastq, EMBL, and GenBank formats). Nevertheless, options are
> > > available to enforce some format specificity such as the encoding
> > > system used in fastq files for quality codes. Most of the basic
> > > Unix commands have their OBITools equivalent (e.g. obihead vs
> > > head, obitail vs tail, obigrep vs grep), which is convenient for
> > > scientists familiar with Unix. The main difference between any
> > > standard Unix command and its OBITools counterpart is that the
> > > treatment unit is no longer the text line but the sequence
> > > record. As a sequence record is more complex than a single text
> > > line, the OBITools programs have many supplementary options
> > > compared to their Unix equivalents.
> >
> > According to the trove information on pypi [1] this is python only,
> > not python3.  We were hoping to not increase the amount of python
> > packages needing
> > porting to python3.  Have you discussed python3 plans with upstream?
> >
> 
> Nope, not yet. However, as I discussed with one guy of the team some
> time ago, I do not think there is any plan to go to python3.
> This is an academic tool, and very often, they only focus on getting
> something working and base maintenance.
> 
> I understand the need to plan python3 switch, however we cannot block
> tools used by the community.

Not every package used by the community needs to be in Debian,
especially if it comes under the classification of "written once,
lobbed over the wall and forgotten" in terms of upstream maintenance.
"base" maintenance includes keeping the package up to date with
dependencies and that means working to get this package clean for
python3 in time for when other dependencies become available. That is
not a small task and if upstream are actually unwilling or unable to
commit to that, then there is no point having the package in Debian
when the stated aim is to make a significant effort on python3 support
for Stretch, extending that further in Buster.

It's tempting to have a package in Debian and I've done this myself in
the past [0] - it turns out to be a quite bad idea if the package needs
to be removed from Debian after only a single stable release due to lack
of maintenance.

Learn from the mistakes of those around you and don't upload packages
which have a "removal timebomb" already primed.

Use a bespoke repository which is available to the people who actually
use it - you may find that it is simpler to then only build the package
against current stable as that is probably what users are actually
running.

[0] https://qa.debian.org/developer.php?login=codehelp - there are too
many packages there which were a good idea at the time but which only
survived for one stable release - the entire GPE suite was already
dying when it got uploaded. Uploading to Debian can *sometimes* inject
life into an upstream project but it can also be a case of flogging a
dying horse.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpez8NfBU3oT.pgp
Description: OpenPGP digital signature


Reply to: