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

Re: Python related autopkgtest anti-pattern

On Saturday, March 21, 2020 1:41:14 AM EDT Scott Kitterman wrote:
> 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

These are filed now (it turned out one package already had a bug, so I added 
information to it instead of filing a new bug).

Scott K

ariba                   Added info to #951944
editorconfig-core-py    #954461
m2crypto                #954462
pydbus                  #954467
pyethash                #954468
pyrlp                   #954469
pysha3                  #954470
pystemd                 #954471
python-daemon           #954473
python-h2               #954474
python-jsbeautifier     #954476
python-jsonext          #954477
python-pbkdf2           #954478
python-pynvim           #954479
python-tinyrpc          #954480
python3-proselint       #954481
pyx3                    #954482
wand                    #954483

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

Reply to: