[Python-modules-team] Bug#855829: Bug#855829: Possible solution

[Neil Williams]

On Mon, 07 Aug 2017 09:09:52 +1000
Brian May <bam at debian.org> wrote:

> Neil Williams <codehelp at debian.org> writes:
> 
> > I'll test this .dsc with django 1.11 and in my local installs of
> > lava-server to make sure it is functional but does this sound like a
> > workable solution for keeping django-tables in Debian? I don't see
> > any other solution to the FTBFS against django1.11 at the moment
> > (#865814).  
> 
> My first thoughts are:
> 
> * Removing a major feature from upstream is bad.

Absolutely agreed. I am unhappy that it could have come to this.
Several other maintainers could have updated their packages over the
last 6 years to avoid this problem. Having said that, it does seem that
upstream has an unusual idea about data set export. LAVA has been
exporting table data using internal functions for some time, to CSV and
YAML. The need to support Microsoft Excel formats does seem a little
unusual - as is the dependency chain of tablib bringing in a language
tool for constructing compilers in order to write out a known data
object to a known data format.
 
> * However removing the feature is probably less evil then dropping the
>   package.
> 
> * We probably should contact upstream about the problem, as it sounds
>   like this means the upstream package is no longer Python3
> compatable - if I understood correctly.

Not quite. PyPi has a version of antlr runtime with python3 support -
version 4.7 when Debian carries 2.7. I'm not sure of the provenance of
that runtime but it would seem sufficient to allow python3 support when
using django-tables solely from PyPi. However, there is no information
available from PyPi about how well tested Python3 support for
django-tables 1.10 may be.

Certainly, the tablib support would make Debian Python3 support in
django-tables2 impossible without fixing the dependencies or making the
export support in django-tables2 optional / omitted from Debian.

https://github.com/bradleyayers/django-tables2/issues/468

I suggest that the first step is to remove the problematic tablib
support from a new 1.10 django-tables upload with a view to closing the
bugs and allowing migration. Later, consideration can be given to adding
the support back *if* tablib is fixed in Debian. More likely, I suspect
that tablib will disappear along with the xsl dependencies and the
python2 runtime for antlr as the Python3 migration moves forward.

Debian Python Policy already warns against new uploads of packages like
tablib without adding include Python3 support.

Maybe a wontfix bug against django-tables tablib support and/or an
entry in README.Debian for the 1.10 upload would be useful too.

-- 


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20170806/4967c716/attachment.sig>