Package: autodep8
Severity: wishlist
(Moving to a new bug: note that I have not decided whether I agree with
this proposal.)
On 31/07/18 14:59, Paul Gevers wrote:
Hi Rebecca,
On 30-07-18 08:57, Rebecca N. Palmer wrote:
On 29/07/18 14:58, Paul Gevers wrote:
[...]
A similar idea has come to my mind
about allow-stderr, so I think this is worth discussing.
Do you mean setting allow-stderr by default in autodep8-generated tests?
That is indeed what I wanted to discuss.
There are packages that would pass only with that (e.g. theano prints a
warning to stderr if one of its Recommends is not installed), but I
don't know how many.
When the debci autodep8 whitelist was being set up, 241 of 1059 Python
packages were found to fail:
https://salsa.debian.org/ci-team/debian-ci-config/commit/c0c8c22d0964d85155b5555367588f0815db6e98
That commit log doesn't say how many of these were due to stderr, but
those 241 might be a good place to look for examples.
Indeed, but right now they shouldn't be using autodep8 then. And I
wonder if there are regression in this area if we want to block on that.
I.e. deprecation warnings in Python are printed on stderr.
DeprecationWarning isn't printed at all by default - does autodep8
enable it (I don't see it doing so, but could be wrong), or were these
some other warning category, or real debian/tests/control files (e.g.
referring to unittest-based upstream test suites, which do enable it)?
If we do set allow-stderr, we might also want to enable
DeprecationWarning to have it visible in the test log (Python upstream
recommend this for test runners:
https://www.python.org/dev/peps/pep-0565/ ), but that might not do much
good if 'pass' logs mostly go unread.
Having a new
Python version being blocked on this is NOT NICE in my opinion. I think
failing on stderr is good by default, but package maintainers have no
way to override it with autodep8, making it unusable by this class of
packages. (This recently came up in the python3.7 transition).
Paul
