On 9 October 2015 at 00:43, Dmitry Shachnev <mity...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud
