56

I ran a build last night, successfully. I got up this morning and ran another without changing any configuration or modifying any source code. Now my build is failing with the message "No source for code" when running my nosetests with coverage. 

NoSource: No source for code: '/home/matthew/.hudson/jobs/myproject/workspace/tests/unit/util.py'
. . . 
No source for code: '/home/matthew/.hudson/jobs/myproject/workspace/__init__.py'

The only clue I have is that the files it says it can't find aren't there, but they never were and they're not supposed to be. For example, in the latter, Hudson's workspace isn't a Python module, so __init__.py wouldn't be there.

Update: I've confirmed that this isn't a Hudson issue. When I run nostests with coverage in the directory itself, I see similar messages. Again, the files that coverage is looking for were never there to begin with, making this very puzzling.

Matt Norris
  • 8,596
  • 14
  • 59
  • 90
  • Does it work again if you do a clean checkout? Perhaps the build process is leaving something behind that's messing up the workspace. – Dave Bacher Mar 05 '10 at 18:05
  • I've wiped out the workspace and rebuilt, but get the same error. I even copied the job under a new name. Is there anything else I can do to assure it's a "clean checkout"? – Matt Norris Mar 05 '10 at 22:31

12 Answers12

51

I'm not sure why it thinks that file exists, but you can tell coverage.py to ignore these problems with a coverage xml -i switch.

If you want to track down the error, drop me a line (ned at ned batchelder com).

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
  • 1
    Thanks, Ned. Is the -i flag documented on your site? I must have missed it. Would you mind posting the link? – Matt Norris Mar 09 '10 at 02:11
  • Hmm, now that you mention it, [the docs](http://nedbatchelder.com/code/coverage/cmd.html) don't seem to mention `-i`, though the command-line help (`coverage help xml`) does. – Ned Batchelder Mar 09 '10 at 13:51
  • @NedBatchelder I'm running into the same sort of problem now. I get a report that projectroot/views.py can't be found, but there is no views.py in the very root of the project. It's as if the module is being forgotten before the source file is looked up, so it's looking in root when it should be looking in root/application/views.py. Any idea where I should start debugging that? Or do you know if '-i' is exposed in the django/nosetest wrapper for coverage? – Ry4an Brase Sep 24 '12 at 19:12
  • 3
    In my case, I had the file `__init__.py` and after an import the file `__init__.pyc` was created. Then I deleted `__init__.py` but forgot the `.pyc` so `coverage.py` was confused. After removing the `__init__.pyc`, all worked fine again. – xbello May 07 '13 at 08:59
  • What is actually needs to be done is to clean all .pyc files and then delete the .coverage file. – Azamat Tokhtaev Jun 20 '14 at 06:36
  • Are we talking about *.pyc files in the pytests directory here? I have problem that running `coverage report` asks for a file on a teammate's computer, so we have something tracked in git that we should not track. I'm trying to figure out how that happens. – pauljohn32 Jun 09 '21 at 16:39
48

Ensure theres no .pyc file there, that may have existed in the past.

Ross
  • 17,861
  • 2
  • 55
  • 73
17

Summary: Existing .coverage data is kept around when running nosetests --with-coverage, so remove it first.

Details: I too just encountered this via Hudson and nosetests. This error was coming from coverage/results.py:18 (coverage 3.3.1 - there were 3 places raising this error, but this was the relevant one). It's trying to open the .py file corresponding to the module that was actually traced. A small demo:

$ echo print > hello.py
$ echo import hello > main.py
$ coverage run main.py

$ rm hello.py
$ coverage xml
No source for code: '/tmp/aoeu/hello.py'

Apparently I had a file stopwords.pyc that was executed/traced, but no stopwords.py. Yet nowhere in my code was I importing stopwords, and even removing the .pyc I still got the error.

A simple strings .coverage then revealed that the reference to stopwords.py still existed. nosetests --with-coverage is using coverage's append or merge functionality, meaning the old .coverage data still lingers around. Indeed, removing .coverage addressed the issue.

Yang
  • 16,037
  • 15
  • 100
  • 142
  • 3
    Great to see that you got to the bottom of it. BTW: instead of `strings .coverage`, you can use `coverage debug data`, which will give you a summary of the data in the `.coverage` file. – Ned Batchelder Jun 28 '10 at 00:39
10

Just use the '--cover-erase' argument. It fixes this error and you don't have to manually delete coverage files

nosetests --with-coverage --cover-erase

I'd strongly recommend checking out the help to see what other args you're missing too and don't forget those plugins either

Adam Spence
  • 3,040
  • 1
  • 21
  • 17
8

The problem is that the .pyc file still exists.

A quick and dirty solution is to delete all .pyc files in that directory:

find . -name "*.pyc" -exec rm -rf {} \;
Rick Hanlon II
  • 20,549
  • 7
  • 47
  • 53
1

I ran into this problem as well when trying to run nosetests coverage through setuptools. As mentioned, it is possible to delete existing .pyc files but that can be cumbersome.

I ended up having to create a .coveragerc file with the following

[report]

ignore_errors = True

to fix this error.

Community
  • 1
  • 1
Danny D'Amours
  • 712
  • 8
  • 17
1

coverage report -m can be called just so, without providing any argument (see official quick instructions). But it works on 1st script coverage-ed, not on 2nd. E.g.

coverage run -m f1.py
coverage report -m # works
coverage run -m f2.py
coverage report -m # fails (f2.py instead of f1.py in last coverage run)

Instead, always indicate script as argument of coverage report -m:

file="f2.py" && coverage run $file && coverage report -m $file

Coverage reporting docs

Xopi García
  • 359
  • 1
  • 2
  • 9
0

Maybe this will help, but I ran into a similar error today. And it's a permission error. My code is using a checkout from another user (by design, down ask) and I need to sudo in order for coverage to work. So your issue may have something to it.

Jorge Vargas
  • 6,712
  • 7
  • 32
  • 29
0

I had this problem. pytest-cov claimed there is no code for existing files full of valid and covered code. I removed those warnings just by removing .coverage file. It is of course recreated on next runs.

Mikaelblomkvistsson
  • 831
  • 10
  • 19
0

A bit another case, but anyway... Don't be foolish as me, use just coverage html, not coverage report html

Давид Шико
  • 362
  • 1
  • 4
  • 13
0

This question was made 13 years ago but today I faced this issue as well and to me, what worked was to delete the .coverage file and run coverage again.

Although the accepted answer works, I don't recommend to do it since it might hide some other issues you might have.

I suspect that for some the reference to a renamed file was left in the index.

Fábio Costa
  • 41
  • 1
  • 2
0

I had this problem, and what solved it was removing the .pytest_cache folder and the *.pyc files

se7en
  • 671
  • 4
  • 18