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

[Neil Williams]

python-tablib should be removed from Debian as it will never (IMHO)
reach python3 support. It is blocked by two bugs, each of which are six
years old with no input from the respective maintainers and the second
bug is in the antlr package which is written in Java and only has
bindings for python2 at the version currently in Debian. The original
maintainers of python-tablib have already indicated that there is no
further interest in the package. I certainly don't have an interest or
expertise in updating the antlr Java package to a new upstream and
adding the python3 bindings.

https://tracker.debian.org/pkg/antlr
It seems likely that the next upload for antlr would drop the python2
bindings when it comes to a requirement for only python3 support.

python-xlwt would be removed for the same reasons.

#865855 (python-tablib) is now blocked by #614502 (python-xlwt) and
#614505 (python-antlr)

The tablib dependency is brought into django-tables upstream in the
1.8.0 release to add export support for the datasets used by each
table. In other words, this is dependency expansion but covering
packages which are already badly maintained in Debian and are at risk
of removal with the move to python3.

The support in django-tables is cleanly isolated and can be handled
by simply removing the newly added files and associated unit tests
instead of needing a patch which needs to be refreshed at future
upstream releases of django-tables.

Adding the tablib dependency to django-tables would seem unnecessary
and undesirable.

I've tested this simple change for debian/rules in django-tables 1.10
(the current upstream release) but this is not suitable as an NMU as it
involves a new upstream release as well.

override_dh_auto_clean:
	dh_auto_clean
	${RM} django_tables2/export/export.py django_tables2/export/__init__.py
	${RM} django_tables2/export/views.py docs/pages/export.rst
	${RM} tests/export/__init__.py tests/export/test_export.py
	${RM} -r .cache django_tables2.egg-info

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).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865814

-- 


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/b5a7f9d5/attachment.sig>