Bug#905153: autodep8: set Restrictions: allow-stderr on generated tests
On Wed, Aug 01, 2018 at 07:53:12AM +0100, Rebecca N. Palmer wrote: > On 01/08/18 02:58, Antonio Terceiro wrote: > > FWIW, most of the supported package types do already set allow-stderr. > > From a quick look, of 4 of 9 explictly set allow-stderr, and 2 append > > `2>/dev/null` to the Test-Command. > > Those being dkms, go, octave, r (allow-stderr) and ruby (2>&1). I don't see > anything using 2>/dev/null for the test itself. sure. I was confused by the usage of 2>/dev/null in nodejs > Is there a reason python isn't on that list? Because no one cared enough to do it. signature.asc Description: PGP signature
Bug#905153: autodep8: set Restrictions: allow-stderr on generated tests
On 01/08/18 02:58, Antonio Terceiro wrote: FWIW, most of the supported package types do already set allow-stderr. From a quick look, of 4 of 9 explictly set allow-stderr, and 2 append `2>/dev/null` to the Test-Command. Those being dkms, go, octave, r (allow-stderr) and ruby (2>&1). I don't see anything using 2>/dev/null for the test itself. Is there a reason python isn't on that list?
Bug#905153: autodep8: set Restrictions: allow-stderr on generated tests
On Tue, Jul 31, 2018 at 11:15:58PM +0100, Rebecca N. Palmer wrote: > 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/c0c8c22d0964d85155b367588f0815db6e98 > > 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. FWIW, most of the supported package types do already set allow-stderr. From a quick look, of 4 of 9 explictly set allow-stderr, and 2 append `2>/dev/null` to the Test-Command. The python support in autodep8 is very much in need of improvement, and we would really benefit from someone who wants to work on it. signature.asc Description: PGP signature
Bug#905153: autodep8: set Restrictions: allow-stderr on generated tests
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/c0c8c22d0964d85155b367588f0815db6e98 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
