-
Notifications
You must be signed in to change notification settings - Fork 214
Possibility to avoid .coverage generation #374
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
Comments
Can you explain why you don't want the .coverage file? Or why you can't simply delete the file? pytest-cov should not be a replacement for all of your dev tools coordination. |
This is something that should be handled elsewhere. However you are running pytest, add a second command to delete the .coverage file if you don't need it. |
when I only want a report, like with the
It's just to make things easier and avoid to type 2 commands instead of one. |
@roipoussiere I am very reluctant to add more complexity to a pytest plugin to make it do more things than run tests. Pytest should run tests. If you want to produce coverage reports after running the tests, it seems reasonable to use another command. You can make those two commands more convenient by creating an alias, or writing a shell script, or a Makefile, or using tox, etc, etc. This plugin is under-maintained and overly complicated. It doesn't make sense to add more to it that can be done elsewhere. |
@roipoussiere you could implement your own pytest plugin to do this and more, it's not that hard. |
@roipoussiere BTW, this has more context: Proposal: pytest-cov should do less |
Faced with this on read-only filesystem in docker. It is because of root user and fast prototyping and I don't want root files in my source. I need only run tests and report coverage to stdout. |
As workaround, use COVERAGE_FILE environment variable. |
I don't see how giving the tool an option that tells it not to leave behind unwanted state is adding responsibilities to the toolkit itself outside of it's currently stated responsibility. There doesn't seem to be very strong logic in the reasoning that the responsibility of pytest-cov is to produce a side effect on your filesystem. The responsibility seems to be to handle code coverage reporting. To assert that file system side effects are an intrinsic artefact of such a responsibility is a fallacy. That is only true if your stated responsibility is to produce coverage reporting that a person may use at some arbitrary point in the future. If that isn't the case, then it is the side effect itself that represents unnecessary complexity in the grand scheme of things. You're spending cycles to do something that no one is asking you to do, and then asking others to spend cycles to remove the thing that they didn't want in the first place. This isn't at least a code smell to you? It isn't a matter of dev tool orchestration - it is about employing a toolkit that is natively compatible with modern delivery pipelines where (ideally) everything is automated and people aren't really in the mix. If that isn't where pytest-cov is aiming to sit, then I can understand the reasoning behind the notion that such an option would complicate the tool's responsibility itself. As it stands now, I had to take a few extra, superfluous steps to ensure that this side effect doesn't cause issues throughout various phases of my project's SDLC. If that doesn't convince you that you have a design problem, then I don't really know what will =\ |
I don't understand your situation. Some automated thing is running pytest, yes? We aren't saying that people should delete the .coverage file. We are saying that whatever runs pytest can also delete the unwanted file. I understand your viewpoint that it seems sloppy to have a file created where none is wanted. I'm sympathetic to that view. But I hope you understand our view that options add complexity, that maintaining a package is real (unpaid) work, and that you have a tool available to you that solves your problem (delete the file). Is there a technical obstacle to deleting the file? Or is this a philosophical debate? |
Any update on this issue ? We need a way to run pytest on read-only filesystem. |
Did you try |
Since this seems to be at the top of google for this particular question (any without a repeatable answer - changes to COVERAGE_FILE did not appear to be respected in my case). Setting this in [tool.coverage.run]
data_file = 'somewhere/.coverage' versions used (python 3.11):
|
Sorry to revive this, but I don't feel like rerouting the export somewhere else is a solution to the initial question. I would argue in favour of reopening this issue, especially with #337 in mind. I can only agree with @pohmelie and @mro-rhansen2 . I only need the stdout of this plugin to check for coverage and don't want a .coverage file to be generated "as a side effect". I can't even open it without external tools, at which point I would rather export it as a json instead. It feels opiniated to ascend one export type over the others. Generating only the files that are explicitly requested (similar to |
The .coverage file is not an export of data. It is the data that is collected while your tests run. Then HTML, text, JSON, or XML reports are generated from that data. So it's not ascended over the other formats, it is central. I'll re-ask the question:
|
Just going to bump that I agree with many above that I think there should be a config flag to delete the |
Making it more extreme for sake of argument: what if this wasn't one file but 100 spread across your project, would one still argue "it's on the user to do the cleanup (cause it's also possible for them)"? |
@raulparada it's just a simple |
Anyone can work around it sure, but it shouldn't be needed. Why not have the |
Putting the file in $TMPDIR would mean that multiple projects would collide if running tests at the same time. That's not good. You aren't going to convince anyone by creating a hypothetical of "imagine there were 100 files" and then suggesting a bad default. How do you manage the |
I support the earlier statements about not saving
|
With this command:
I explicitly want to generate an xml file, but a
.coverage
file is also generated. It could be nice to have the possibility to don't generate this file, for instance with a--no-cov-file
(or similar) option.The text was updated successfully, but these errors were encountered: