[TIP] ImportError (No module named 'pytest') - weird coverage and py interaction as a result of tox dependency

[Chris Withers]

Hi All,

So, with:

nosetests --with-xunit --with-cov

...I get the following failures on Python 3.* in Linux and Mac:

ERROR: Failure: ImportError (No module named 'pytest')

Full and nasty traceback here:

http://jenkins.simplistix.co.uk/job/testfixtures-virtualenv/PYTHON=3.4,label=linux/333/testReport/junit/nose.failure/Failure/runTest/

The weird thing is that if I drop the --with-cov, things work fine.

Has anyone seen anything similar?

None of the packages involved seem to have changed recently, so I'm a
little at a loss as to what has changed.

Chris

[Chris Withers]

Post by Chris Withers
Hi All,
nosetests --with-xunit --with-cov
ERROR: Failure: ImportError (No module named 'pytest')

Just to spice this up further: the failure is intermittent on Mac :-(

Chris

[Chris Withers]

Post by Chris Withers
Hi All,
nosetests --with-xunit --with-cov
ERROR: Failure: ImportError (No module named 'pytest')
http://jenkins.simplistix.co.uk/job/testfixtures-virtualenv/PYTHON=3.4,label=linux/333/testReport/junit/nose.failure/Failure/runTest/
The weird thing is that if I drop the --with-cov, things work fine.

Some more digging has revealed something interesting.

So, by the time the problematic import statement in test_docs.py is his,
when nose is run --with-cov, sys.modules has 310 keys versus the 260 it
has when run without --with-cov.

When run without coverage, they're all the same type:

(Pdb) set(type(v) for v in sys.modules.values())
{<class 'module'>}

When run with coverage, we get a bunch of things:

(Pdb) set(type(v) for v in sys.modules.values())
{
<class 'py._apipkg.ApiModule'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>,
<class 'module'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>
}

...one of which causes problems when the manuel package's introspection
tries to do:

24 -> def absolute_import(name):
25 module_path = normalize_module_path(imp.find_module(name)[1])
26
27 # don't create a new module object if there's already one
that we can reuse
28 for module in list(sys.modules.values()):
29 if module is None or not hasattr(module, '__file__'):
30 continue
31 if module_path == normalize_module_path(module.__file__):
32 return module

(Pdb) hasattr(sys.modules['py.test'], '__file__')
*** ImportError: No module named 'pytest'

So, any ideas?

Chris

[holger krekel]

Post by Chris Withers

Post by Chris Withers
Hi All,
nosetests --with-xunit --with-cov
ERROR: Failure: ImportError (No module named 'pytest')
http://jenkins.simplistix.co.uk/job/testfixtures-virtualenv/PYTHON=3.4,label=linux/333/testReport/junit/nose.failure/Failure/runTest/
The weird thing is that if I drop the --with-cov, things work fine.

Some more digging has revealed something interesting.
So, by the time the problematic import statement in test_docs.py is
his, when nose is run --with-cov, sys.modules has 310 keys versus
the 260 it has when run without --with-cov.
(Pdb) set(type(v) for v in sys.modules.values())
{<class 'module'>}
(Pdb) set(type(v) for v in sys.modules.values())
{
<class 'py._apipkg.ApiModule'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>,
<class 'module'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>,
<class 'py._apipkg.AliasModule.<locals>.AliasModule'>
}
...one of which causes problems when the manuel package's
25 module_path = normalize_module_path(imp.find_module(name)[1])
26
27 # don't create a new module object if there's already
one that we can reuse
30 continue
32 return module
(Pdb) hasattr(sys.modules['py.test'], '__file__')
*** ImportError: No module named 'pytest'
So, any ideas?

There is some import-machinery-using compatibility code in ``py`` to
make ``py.test`` resolve to ``pytest``. Maybe some bad interactions
go on here with coverage but can't dig further at the moment. You might
check in your own code if anything is using py.test instead of pytest,
but it's probably triggered somewhere else.

holger

Post by Chris Withers
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk