automating the subprocess measurement setup

Issue #367 closed
Tibor created an issue

Subprocesses in test suits are a common occurence. has an execellent way to measure their coverage but the set-up instructions are quite scary:

Also in the time of tox, continuous integration, virtualizations and containerizations, the manual process is quite beside the point.

What could we do to completely automate the described process?

There is an article by Ned

and a suggestion from @geoffbache

import os, sys
currDir = os.path.dirname(__file__)
del sys.modules["sitecustomize"]
    import sitecustomize
    sys.path.insert(0, currDir)

That script fails on my machine (MacOS, Python 2.7) with

Traceback (most recent call last):
  File "/Users/tibor/.virtualenvs/tmon/bin/../lib/python2.7/", line 703, in <module>
  File "/Users/tibor/.virtualenvs/tmon/bin/../lib/python2.7/", line 694, in main
  File "/Users/tibor/.virtualenvs/tmon/bin/../lib/python2.7/", line 548, in execsitecustomize
    import sitecustomize
  File "/Users/tibor/tmonworkspace/testmon/", line 8, in <module>
    sys.path.insert(0, currDir)
AttributeError: 'NoneType' object has no attribute 'path'

But I would hope that it's the best approach.

Comments (6)

  1. Tibor reporter

    Nice approach, I guess. I'm still getting ImportError: No module named 'coverage' on of coverage (tox/pip somehow always installs the pth file first and only then attempts to run python of coverage, which fails because there is no yet)

  2. Tibor reporter

    The problem I had is only with --editable coveragepy. So yes, it's definitely a solution! Could you include it in coveragepy itself?

  3. Buck Evan

    The cov-core solution doesn't uninstall whatsoever. In fact it causes the whole virtualenv to explode (ImportError) if you uninstall it.

    The coverage-pth solution is better, but doesn't handle develop aka pip install -e.

    The solution found in python-hunter handles all those cases, in addition to supporting easy-install.

    We've recently adapted this into a package that fills the same problem space as coverage-pth, but is more reliable.

    IMO this should be a default feature of coveragepy. While it will add one if-statement to all subsequent python startup time, that seems like a near-zero cost to me, and the additional use-cases supported are sizeable.

  4. Log in to comment