On Fri, Apr 22, 2005 at 20:45 -0500, Ian Bicking wrote:
Could you post one of the offending tracebacks?
To repeat:
$ svn co http://codespeak.net/svn/user/ianb/py_test_import_failure A py_test_import_failure/import_fails.py A py_test_import_failure/test_import_fail.py Checked out revision 11048. $ cd py_test_import_failure/ py_test_import_failure$ py.test inserting into sys.path: /home/ianb/py/dist ============================ test process starts ============================ testing-mode: inprocess executable: /usr/bin/python (2.3.5-final-0)
py_test_import_failure/test_import_fail.py[-1] F _____________________________________________________________________________
def test_this(): E assert import_fails.a == 1
AttributeError: 'module' object has no attribute 'a'
[/home/ianb/t/py_test_import_failure/test_import_fail.py:4] [modulepath: test_this] _____________________________________________________________________________ ================= tests finished: 1 failed in 0.02 seconds =================
OK, this one is actually related to a different problem, namely that the "[]" number in: py_test_import_failure/test_import_fail.py[-1] F it basically means that we try early to look forward to determine the number of tests. This is where the import fails. Later when the module is really run for error reporting the imports don't fail anymore (at least on python <2.4). Funny, that our custom import hook didn't have this problem because it could emulate python2.4 behaviour (deleting a failed import from sys.modules recursively). There are many paths that lead to hell starting from a simple import. Anyway, i fixed py.test to a) get around the problem and b) report a nice traceback. Thanks for pointing it out and providing an example! Actually i named the test that i added after you :-) cheers, holger