[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python related autopkgtest anti-pattern



On Wednesday, March 18, 2020 6:32:22 PM EDT Scott Kitterman wrote:
> I'm currently reviewing some of the autopkgtest regressions that are
> currently blocking python3-defaults with python3.8 as the default python3
> from migrating.
> 
> With the current state of the environment being used for autopkgtest it is
> quite common for python3.7 to be present in the environment even if it's not
> explicitly required by a dependency.  As a result, I seen many failures
> where the test attempts to loop through python3 versions (a good thing)
> based on what versions are installed (bad thing).
> 
> We want the tests to run against all versions, but the way to do that is to
> have your test depend on python3-all (to make sure that all supported
> versions are installed) and then use the -s flag for py3versions vice -i. 
> So (in one common pattern) this:
> 
> for py in $(py3versions -i); do
> 
> changes to:
> 
> for py in $(py3versions -s); do
> 
> Makes all the difference in the world.  I've fixed three today.  If you care
> for a relevant package, please check.  The future pain you save may be your
> own.
> 
> Scott K

I have continued to look into this and it's common enough that there are quite 
a few related autopkgtest failures currently marked as regressions against 
python3-defaults with python3.8 as the default python3.

Except for one I filed earlier, none of them have bugs currently.  It's enough 
I'm not sure if it qualifies as a MBF for not.  Here's what I'll file if I get 
sufficiently motivated and have the time:

This package failed a recent autopkgtest and this is one of the blockers for 
python3-defaults migration.  It failed because python3.7 was installed in the 
chroot and the current autopkgtest doesn't handle that.

Autopkgtests should be run for all supported versions.  The package attempts 
to do that, but in a way that is unreliable.

Based on a review of the failure log (I have not looked at the package, so 
there's a small chance the root cause is different), the autopkgtest uses the 
output of py3versions -i to iterate over available python3 versions.  The -i 
flag indicates all installed versions.  In many cases python3.7 is still 
partially installed, so it is included in the tests, but fails.

The reliable way to do this is add python3-all to your tests depends in 
debian/tests/control and change the py3versions call to py3versions -s.  These 
two steps will ensure all supported python3 interpreters are fully installed 
and that the tests are run against them.

As this is a blocker for getting python3.8 as default python3 into bullseye, 
please address this soon.  I'm open to doing NMUs if anyone would like the 
support.  Please let me know if you would like for me to do that.

Scott K

dd-list is attached.  If any of you fix these before I file the bugs, please let 
me know so I can skip that package when I do.

Scott K
Alberto Caso <alberto.caso@juntaex.es>
   pydbus (U)

Alessio Treglia <alessio@debian.org>
   python-pbkdf2

Alexandros Afentoulis <alexaf.dpkg@bloom.re>
   pystemd (U)

Andrej Shadura <andrewsh@debian.org>
   python-h2 (U)

Ben Finney <bignose@debian.org>
   editorconfig-core-py
   pyethash
   pyrlp
   pysha3
   python-daemon
   python-jsonext
   python-tinyrpc

Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
   ariba

Debian Python Modules Team <python-modules-team@lists.alioth.debian.org>
   m2crypto (U)
   pydbus
   pystemd
   python-h2
   python-pynvim
   python3-proselint

Håvard Flaget Aasen <haavard_aasen@yahoo.no>
   python-jsbeautifier
   wand

James McCoy <jamessan@debian.org>
   python-pynvim (U)

Sandro Tosi <morph@debian.org>
   m2crypto

Sascha Steinbiss <satta@debian.org>
   ariba (U)

Stuart Prescott <stuart@debian.org>
   pyx3

Víctor Cuadrado Juan <me@viccuad.me>
   python-pynvim (U)
   python3-proselint (U)

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: