-
-
Notifications
You must be signed in to change notification settings - Fork 438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhelpful warnings produced when using source directive and subprocess measurement #96
Comments
I definitely see your points here. The purpose of the warnings was to help people new to coverage to diagnose why they weren't getting the results they expected. So I'm going to leave them enabled by default. We can either disable them entirely with an rcfile setting, or provide a way to disable them individually, which is probably overkill. |
Original comment by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown) OK. Couldn't you achieve the first point with some kind of --debug / --verbose option? (i.e. documented as "enable this if you don't understand what's going on"?) I see your point re newbies but I think it isn't good to have things enabled by default that will often just be wrong. As far as I can see, they're only really useful if you're testing a single process in their current form. |
Original comment by wigbam (Bitbucket: wigbam, GitHub: wigbam) This issue caused some pain to us as well. We are using pytest (and therefore pytest-cov and cov-core) to run tests within our company. When pytest-cov runs it creates coverage controller with explicit set of modules to collect coverage for, which is then also applied to all sub-processes (as far as my understanding goes). Since a few of our tests parse the output from a sub-process they were failing due to warnings from coverage being present in the output. In the end I had to patch coverage to provide a possibility to disable all coverage warnings by setting an environment variable. Therefore, in ideal case I would vouch for disabling coverage warnings for all sub-processes by default and only display them when aggregated output is generated at the test session end. Not sure if this needs to go into pytest-cov/cov-core or into coverage itself, though. |
Original comment by Daniel Blanchard (Bitbucket: daniel_blanchard, GitHub: Unknown) Is there a way to disable them in the rcfile? |
Issue #355 is asking for a way to suppress warnings, which I think is a good idea. |
Original comment by Simon Ye (Bitbucket: yesimon, GitHub: yesimon) It seems like an easy-ish thing to add to the config to control I'm also getting these warnings run through pytest-cov, so a config variable should do the trick nicely. |
Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary) For the record here is a proposed fix https://bitbucket.org/ned/coveragepy/pull-requests/110/add-no-warnings-to-run-cmd-to-silence/diff |
I liked the idea of individually suppressable warnings, rather than a huge hammer that turns them all off. Other opinions? |
Implemented in 70ca90597acd (bb) |
This is in 4.4b1. |
Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)
When I specify my source in the [run] section of the rc file, and run coverage by setting COVERAGE_PROCESS_START, I get a lot of spurious warnings printed on standard error.
It says "Source module %s was never encountered." and occasionally "No data was collected."
Obviously not every subprocess will necessarily load every source module, and indeed it's perfectly OK to have some python subprocess somewhere which doesn't run any of my code.
The first warning is also a pain when running multiple tests in different processes: I want to have one rc file saying where my source is without needing every test to load every module.
I'd question whether these warnings are useful at all: but at least there should be some way to disable them, and preferably they should be off by default.
The text was updated successfully, but these errors were encountered: