Coverage.py Python Module - Import Errors when Running Script

Question

I'm having trouble getting the "coverage" module for Python working correctly.

I have no permissions to modify or add to Python directory, so am unable to install easy_install to setup coverage.

Worked around this by adding the coverage directory to my python path. Coverage works fine, inputting coverage --version to shell outputs the version. coverage help displays all the commands available. Everything seems fine.

I can run coverage fine on small simple scripts.

However, when running a large script with a number of imports across 5 modules (a script that has been tested as working), when running the command with coverage run [normal commands], the script executes and fails, because some modules cannot be found.

Here's a breakdown:

Command line without coverage (working fine):

I invoke the script by running: ./script_name.py arg1 arg2 arg3

When I try running the script by inputting: python script_name.py arg1 arg2 arg3, the script fails, failing to import modules:

ImportError: No module named cx_Oracle

Command line with coverage:

$ coverage run ./script_name.py arg1 arg2 arg3

"No file to run: 'main.py'"

$ coverage run {full_path_to_module_name}/script_name.py arg1 arg2 arg3

Now we are getting somewhere. Coverage is clearly invoked and working, but I get that import error:

ImportError: No module named cx_Oracle

score 16 · Answer 1 · answered Jul 18 '19 at 09:00

16

I think I had a similar issue, and managed to solve it by running coverage like this:

python -m coverage run [normal commands]

Specifically in my case it was

python -m coverage run -m unittest discover

It definitely seems to be a case of coverage using a different python installation, as my module that was reported missing was only installed in my virtual env and not in my global env.

answered Jul 18 '19 at 09:00

Jordan Mackie

2,264
4
25
45

1

It should also work with just `coverage run -m unittest discover` – Yitzchak Blank Aug 19 '19 at 15:23
1

This worked great. But when I do `coverage report -m` then it gives me all the library files as well. I tried giving `--source` but the command didn't accept that. – Ganesh Satpute Oct 15 '19 at 11:21

score 5 · Accepted Answer · answered Aug 15 '11 at 13:01

5

The good news is, running with "python" explicitly, and with coverage.py produce the same result. The bad news is, that result is an error message.

It seems like you have more than one Python installation. One is found by "./script_name.py", the other is found by "python ./script_name.py".

To diagnose the problem, add these lines to the top of script_name.py:

import sys
print sys.executable
print "\n".join(sys.path)

This will show you the Python executable being invoked, and the search path for modules. Running your script both ways will show you different results, and you should be able to figure out what is going on.

answered Aug 15 '11 at 13:01

Ned Batchelder

364,293
75
561
662

Hi Ned. Thanks for your support and well done on the excellent package. I've used it locally without these problems and it works wonders. I was wondering if you could direct me to the right place in sorting this problem out. You're right that invoking "python [script name]" without the module throws out the same errors. Ideally I would like to just call "coverage run /{full_path_to_script_name.py}" and have it run but I'm getting a "No file to run: "/{full_path_to_script_name.py}" error. Any thoughts? The command works fine without "coverage run". Thanks – mamoma Aug 16 '11 at 08:52
No worries, fixed it! I think the problem was quite unique to the environment I'm running, but I had to change a few paths in files and include some other ones. Bit of a maze, but happy to elaborate if it will be of benefit to someone else. – mamoma Aug 16 '11 at 10:05
1

@NedBatchelder: I think I am hitting similar problem, and your answer helped to diagnose it. I am running inside `virtualenv` and `python -c 'import sys; print(sys.executable)'` gives me location within virtualenv, but when I execute it using `coverage run`, it shows me system interpreter. Could you share on how to deal with that and ask `coverage` to use virtualenv that is currently activated? – Tadeck Sep 23 '13 at 12:01
@NedBatchelder: I have added a question on that (http://stackoverflow.com/q/18959072/548696). I believe it is either trivial, or already solved, but I cannot find solution. – Tadeck Sep 23 '13 at 12:20

score 1 · Answer 3 · answered Nov 15 '19 at 14:41

I will add my experience, as someone could fall into the same mistake.

I was running coverage inside a python virtual environment (venv) with coverage not installed. Executing coverage I was in fact calling the coverage installed globally.

Installing locally with pip3 install coverage solved it for me, now using python3 -m coverage run myfile.py.

score 0 · Answer 4 · answered Jul 08 '20 at 08:08

I have just encountered a very similar issue where using either of the following worked for me locally:

coverage run

python -m coverage run

So locally whenever I ran make unit-test either of these worked fine, yet when I deployed my code to codebuild on AWS neither of these make targets worked.

I finally put this down to the fact that over time I had installed coverage locally, and into my local environment, but on starting to use pyenv I also installed this into my pyenv environment, so three places locally.

When running on the build agent I was in fact ONLY installing this into a fresh pyenv environment, and so I had to use the following syntax:

python -m pipenv run coverage run --source=src/app -m pytest -s --junitxml=result.xml src/test/unit/*.py

I guess the moral of my story is to keep your working environment clean, which I will endeavour to do from now on.

This might help somebody out in a similar situation, which is why I am posting.

Coverage.py Python Module - Import Errors when Running Script

4 Answers4