1. Ned Batchelder
  2. coverage.py
  3. Issues
Issue #365 new

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

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