63

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.

Improve this question
2
  • Does it work again if you do a clean checkout? Perhaps the build process is leaving something behind that's messing up the workspace. Commented Mar 5, 2010 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"? Commented Mar 5, 2010 at 22:31

12 Answers 12

Reset to default
63

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).

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Thanks, Ned. Is the -i flag documented on your site? I must have missed it. Would you mind posting the link?
Hmm, now that you mention it, the docs don't seem to mention -i, though the command-line help (coverage help xml) does.
@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?
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.
What is actually needs to be done is to clean all .pyc files and then delete the .coverage file.
|
55

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

Improve this answer

2 Comments

In my case, this is exactly what helped - delete all *.pyc and also .coverage and all xml files present.
Awsome! This should be the accepted answer :)
20

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.

Improve this answer

1 Comment

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.
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

Improve this answer

Comments

10

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 {} \;
Improve this answer

1 Comment

A shortcut: find . -name "*.pyc" -delete
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.

Improve this answer

2 Comments

Rather than ignore the problem, better to understand and correct it. Ignoring errors that can be addressed is usually bad practice.
This really fixed it for me. Thank you
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

Improve this answer

Comments

1

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.

Improve this answer

Comments

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.

Improve this answer

Comments

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.

Improve this answer

Comments

0

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

Improve this answer

Comments

0

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

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.