Package: src:python-static3
Version: 0.7.0-5
Severity: serious
Hi there,
tox's (new) maintainer here. python-static3 uses "tox" as an
autopkgtest, which is currently broken and that holds a newer version of
tox from migrating to testing. (Hence setting the severity to serious)
The use of tox here as an autopkgtest doesn't make a lot of sense to me
for the following reasons:
* This currently relies on the network to work, as it fetches
dependencies over from pypi. That could be addressed with
--sitepackages, however.
* This also means that the tests are against dependencies from pypi, not
the versions in Debian. That's not really a Debian package test then,
just an upstream test, and I'm not sure what the point of that is --
presumably upstream is already doing that given they ship a tox.ini?
* In turn, this also means that those tests may fail at any point in
time, because of changes outside of Debian. I think this is the case
right now while I was trying to reproduce the debci failure (I get an
unrelated backtrace from the pypi package "kid").
* Even more to it, this tests against Python versions set by upstream,
which are currently set to:
envlist = py26, py27, py33, py34, pypy
The package doesn't build Python 2 binaries, so these are out; it does
not Build-Depend on pypy so that's out too; and the Python 3 versions
are not versions that exist in sid/testing. So these tests are really
not for any of the Python versions shipped in Debian...
* At the end of the day, the upstream tox just has a
commands=python setup.py test []
...which could be the command that autopkgtest runs. However, it may
make more sense to just run that as part of the dh_auto_test step, as
it runs the upstream tests and not any kind of Debian integration
tests.
TL;DR: I'd remove the autopkgtest altogether, and make sure that
"python3 setup.py" when the package builds e.g. as part of dh_auto_test.
YMMV :)
Regards,
Faidon
