pytest-cov
                                
                                 pytest-cov copied to clipboard
                                
                                    pytest-cov copied to clipboard
                            
                            
                            
                        Use the very same configuration file passed with -c to pytest
Hello,
Imagine you have 2 setupXXX.cfg files in your repository, both containing (different) configuration for the coverage.
When I run pytest -c setup.cfg (or I simply omit the -c option) everything is fine.
If I run instead pytest -c setup2.cfg, it looks like setup.cfg is used instead for the coverage configuration, instead of setup2.cfg.
Now, I've read that one can/should use --cov-config, but I guess that the default behavior should be reading the same configuration file as the one passed with the -c option to pytest.
Versions: pytest-cov-2.6.1 pytest-4.4.0
Thanks.
It would break things for lots of users if we use the main pytest config as coverage config as default.
What's the actual problem you are having? Explain a bit your use-case.
Well, the use case is using pytest -c <some setup> and expect coverage to use the setup in the configuration file passed to pytest.
Otherwise, I don't really understand what is the purpose of having a coverage configuration in the setup.cfg in first place :)
Thanks for the quick answer btw.
It wasn't all designed from the start ... pytest and coverage are separate projects and have different history and design decisions, it shouldn't be a surprise things aren't perfectly aligned.
My question was actually about why you need multiple pytest configuration files, as in your initial example.
At work, we have the same python library being used in different environments, that are not heterogeneous. In one of this environment, we are building some combined coverage, which requires the option "branch" to be the same on all the initial computed coverage. For that reason, we need different way to compute the coverage.
Since [coverage:xxx] is part of the setup.cfg, I would assume that the optimal solution would be having a different setup.cfg depending on the environment you are in, which is not the way the plugin work.
We have an easy workaround, so no big deals, but I was more asking myself if it was intended or not.