Re: Python < 3.5 tests

[Robert Collins <robertc@robertcollins.net>]

On 9 October 2015 at 00:43, Dmitry Shachnev <mitya57@debian.org> wrote:
> Hi all,
>
> On Thu, 8 Oct 2015 08:12:22 +1100, Brian May wrote:
> [...]
>> So it looks like it can't find the tests under Python 2.7 or Python 3.4,
>> so it use to work, however under Python 3.5 it now does find the tests
>> and they fail.
>>
>> This left me wondering:
>>
>> * Why does it not find the tests under Python 2.7, 3.4? What is
>>   different about Python 3.5 that it does?
>
> There was a change in unittest autoloader in Python 3.5. It now tries to
> import the package even if it has no tests. I do not know if it is an
> intended change, or a side-effect of fixing some bug ([1]?). Maybe Robert
> can enlighten us here.

Imagine I have a directory with __init__.py and test_foo.py, and a
subdir (sub) of that with __init__.py and test_bar.py.
Before that change, __init__ was loaded and test_foo was loaded. and
sub/__init__ was loaded, then if present the load_tests hook in
sub/__init__ is fire, and finally test_bar.py is loaded.

After the change the root __init__ is examined for a load_tests hook
as well. So the only time this specific patch would change behaviour
is if discover's start dir was a package (vs a namespace package aka
directory) and __init__ has a load_tests hook.

As discover is being run with a start of ., thats not the impact here.

But - ajax_select/__init__.py is going to be imported, and thats whats
erroring. I don't think that this is a 3.5 unit testing change - I
think its an error importing some bit of django.

The test suite output should show the actual import error exception,
whats been pasted here so far has just been the loader stage output,
but the loader returns a thunk that will show the exception that
occurred during loading and would help debugging.

> This has caused some my packages to FTBFS too, for example see bugs
> #800671 and #800139. So if it not an intended change, it should be fixed
> upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800671 shows this:

    "/tmp/buildd/python-changelog-0.3.4/.pybuild/pythonX.Y_3.5/build/changelog/__init__.py",
    line 3, in <module>
      from .changelog import setup
    File
    "/tmp/buildd/python-changelog-0.3.4/.pybuild/pythonX.Y_3.5/build/changelog/changelog.py",
    line 5, in <module>
      from sphinx.util.compat import Directive
  ImportError: No module named 'sphinx'

And pybuild has cd'd to the build dir there before running discover.
So - changelog's __init__ can't be imported - that should occur in all
versions of discover, when changelog is imported and scanned, because
importing anything from within it will need to initialise the package
first, which is basic Python semantics.

800139 has the same issue.

Any tests of these packages will need to import the package itself to
exercise it, so I don't see a CPython/discover bug here.

-Rob

-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud