coverage + nose + mako resulting in "No source for code:" on compiled module for template

Issue #365 new
Michael Merickel
created an issue

I'm having trouble tracking this down but something is going on between nose and coverage.

The broken commit is here, where I tried to add coverage reports for our tests, as well as the source package.

https://github.com/Pylons/pyramid_debugtoolbar/compare/2a5a30a8d33cf0e51bfb50d8b3487f1e9c6d6b36...add-coverage-on-tests

Executing the following commands:

$ virtualenv env
$ env/bin/python setup.py dev
$ env/bin/coverage erase
$ env/bin/coverage run --source=pyramid_debugtoolbar,tests env/bin/nosetests
$ env/bin/coverage xml
No source for code: '/Users/michael/work/oss/pyramid_debugtoolbar/tests/pyramid_debugtoolbar_templates_exception_dbtmako': [Errno 2] No such file or directory: '/Users/michael/work/oss/pyramid_debugtoolbar/tests/pyramid_debugtoolbar_templates_exception_dbtmako'

The path munging code inside mako is generating pyramid_debugtoolbar_templates_exception_dbtmako and someone is turning that into tests/pyramid_debugtoolbar_templates_exception_dbtmako.

https://github.com/zzzeek/mako/blob/22fb044c3cb177aa197af1877c1c67e3f70066b7/mako/template.py#L247-254

Note that the original template is at the path pyramid_debugtoolbar/templates/exception.dbtmako.

The weirder parts are that nose's where=tests/ option in setup.cfg breaks this. The following patch will fix everything by specifying the tests folder on the CLI. However, if I use -w tests (effectively the same as the where=tests/) then things break.

diff --git a/setup.cfg b/setup.cfg
index 58e2803..7cbc718 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -6,7 +6,7 @@ zip_ok = false

 [nosetests]
 match=^test
-where=tests/
+#where=tests/
 nocapture=1

 [aliases]
diff --git a/tox.ini b/tox.ini
index 55cac15..7666421 100644
--- a/tox.ini
+++ b/tox.ini
@@ -25,7 +25,7 @@ commands =
 [testenv:py2-cover]
 commands =
     pip install pyramid_debugtoolbar[testing]
-    coverage run --source=pyramid_debugtoolbar,tests {envbindir}/nosetests
+    coverage run --source=pyramid_debugtoolbar,tests {envbindir}/nosetests tests
     coverage xml -o coverage-py2.xml
 setenv =
     COVERAGE_FILE=.coverage.py2
@@ -33,7 +33,7 @@ setenv =
 [testenv:py3-cover]
 commands =
     pip install pyramid_debugtoolbar[testing]
-    coverage run --source=pyramid_debugtoolbar,tests {envbindir}/nosetests
+    coverage run --source=pyramid_debugtoolbar,tests {envbindir}/nosetests tests
     coverage xml -o coverage-py3.xml
 setenv =
     COVERAGE_FILE=.coverage.py3

In any scenario I can come up with so far running env/bin/nosetests --with-coverage --cover-package=pyramid_debugtoolbar,tests --cover-tests --cover-xml tests dumps out a valid xml file. However, I would like to use the coverage command directly and not through nose.

Please any insight would be helpful as the PylonsProject is investigating using this pattern in many projects.

I tested this against 3.7 and 4.0a5 with the same results.

Looking at env/bin/coverage debug data in both scenarios (coverage run and nosetests --with-coverage) shows the following:

<snip>
/Users/michael/work/oss/pyramid_debugtoolbar/tests/pyramid_debugtoolbar_templates_exception_dbtmako: 81 lines
/Users/michael/work/oss/pyramid_debugtoolbar/tests/pyramid_debugtoolbar_templates_exception_summary_dbtmako: 29 lines
/Users/michael/work/oss/pyramid_debugtoolbar/tests/pyramid_debugtoolbar_templates_redirect_dbtmako: 29 lines
<snip>

However if I remove the -w (the only working scenario described earlier using coverage run), those files are not listed in debug data.

Comments (7)

  1. Michael Merickel reporter

    @Ned Batchelder Obviously it's been a while. I can tell you the behavior in the notes was observed by several other developers on their own machines. We spent several hours going through permutations that would dump out a proper report but in the end I think dropping the -w caused both systems to just ignore the missing coverage on the templates.

  2. Ned Batchelder repo owner

    @Bert JW Regeer if you could make the filenames be less misleading, that would be great :) Or give me some other idea about how to handle this. The ideal case is that someone writes a plugin for these template languages. Then you might also get coverage measurement of the templates!

  3. Log in to comment