Request for command line argument to set data_file path

[BlacKCaT27]

Currently, the only option for setting the data_file path is to use either the COVERAGE_FILE environment variable or set the data_file field in .coveragerc. However, neither of these work well for my use case.

In my setup, I'm using Visual Studio Code and have a plugin which runs commands I specify when certain events are triggered. I've configured the following command to run my unit tests and run coverage using pytest-cov:

"python -m pytest --cov=Scripts --cov-config ${workspaceRoot}/.coveragerc --cov-report html:${workspaceRoot}/locale/coverage_html --cov-report xml:${workspaceRoot}/local/coverage.xml --cov-report annotate:${workspaceRoot}/local/coverage_annotate ${workspaceRoot}/UnitTests/"

The issue that because it's VS Codes plugin system performing the actual execution of the command, the working directory at time of execution is C:\Program Files\Microsoft VS Code, not the directorying containing my Scripts module. This results in Coverage throwing an exception since that area of the file system is write-protected.

If there were a command line argument to set the data_file path, I could set that in my command here and be all set, and not have to use an environment variable, which I'd like to avoid as it makes the solution harder to migrate to other systems (e.g. our CI system).

[ionelmc]

Seems ridiculous at first glance that you can't set the CWD. What plugin is this?

[BlacKCaT27]

https://github.com/emeraldwalk/vscode-runonsave

I agree it's frustrating that the default execution path is a write-protected area and that it isn't editable (to my knowledge, I submitted an issue there as well so perhaps I'll be corrected).

I'm exploring a workaround for this issue by writing a python script which invokes Coverage.py for me, which I then invoke with RunOnSave, passing in the directory I intent for Coverage.py to actually care about. But this is

a) needlessly complex for what should be a straightforward solution

b) For whatever reason I've yet to debug, I can't seem to get my coverage plugins to execute using this strategy (likely because I'm not registering them properly, because I'm not 100% sure how when executing coverage from python directly).

That being said, my original issue still remains: having a parameter to specify the data_file location would be extremely helpful, if it's technically achieveable.

[ionelmc]

Why not make a wrapper that uses correct run dir then? Eg:

cmd /c "cd ${workspaceRoot} && python -m pytest --cov=Scripts --cov-config ${workspaceRoot}/.coveragerc --cov-report html:${workspaceRoot}/locale/coverage_html --cov-report xml:${workspaceRoot}/local/coverage.xml --cov-report annotate:${workspaceRoot}/local/coverage_annotate ${workspaceRoot}/UnitTests/"

Also, you can remove all the absolute paths, this would work just as well:

cmd /c "cd ${workspaceRoot} && python -m pytest --cov=Scripts --cov-report html:locale/coverage_html --cov-report xml:local/coverage.xml --cov-report annotate:local/coverage_annotate UnitTests/"

This request seems superfluous, there has to be a more restrictive usecase in order to justify yet another option in pytest-cov.

[BlacKCaT27]

Wow...I feel a bit silly now honestly. It never occurred to me to append multiple statements into the command argument to change the directory myself...That's working beautifully and negates the need for my python wrapper. Thanks for that.

I personally would still argue for adding the option to specify the write directory. When it comes to libraries which are to be used by unknown callers with unknown use cases, I tend to err on the side of "maximum configurability with minimum required configuration thanks to sensible defaults". Anything that writes something to disk should have that target be configurable, imo. But now we're getting more into design philosophy and not supporting a specific need, and it's your guys' library (which you guys support) so I totally understand not wanting to add complexity for dubious reasons.

Thanks for your help!