Possibility to avoid .coverage generation

[roipoussiere]

With this command:

pytest --cov=app --cov-report=xml --junitxml $PYTEST_XML_PATH

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.

[nedbat]

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.

[nedbat]

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.

[roipoussiere]

Can you explain why you don't want the .coverage file?

when I only want a report, like with the --cov-report=xml option.

Or why you can't simply delete the file?

It's just to make things easier and avoid to type 2 commands instead of one.

[nedbat]

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

[ionelmc]

@roipoussiere you could implement your own pytest plugin to do this and more, it's not that hard.

[nedbat]

@roipoussiere BTW, this has more context: Proposal: pytest-cov should do less

[pohmelie]

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.

[em92]

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.
Example COVERAGE_FILE=/tmp/junk.coverage. Already tried /dev/null, it didn't work, 'cos pytest-cov tries to delete this file.

[mro-rhansen2]

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 =\

[nedbat]

everything is automated and people aren't really in the mix

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?

[admo1]

Any update on this issue ? We need a way to run pytest on read-only filesystem.

[nedbat]

Any update on this issue ? We need a way to run pytest on read-only filesystem.

Did you try COVERAGE_FILE=/someplace/writable/.coverage?

[BrendanJM]

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 pyproject.toml, however, did the trick:

[tool.coverage.run]
data_file = 'somewhere/.coverage'

versions used (python 3.11):

coverage=7.4.0
pytest=7.4.4
purest-dov=4.1.0

[ModischFabrications]

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 --cov-report json) would be perfect, but if that isn't something to agree on I would at least like an option to skip these files with --no-export or anything similar.

[nedbat]

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:

Is there a technical obstacle to deleting the file? Or is this a philosophical debate?