Attempt to get configuration from setup.cfg if .coveragerc is not present
Before I start, I have no idea how trivial or difficult this would be.
I propose that, if there is not a .coveragerc file present in (the directories that it looks for them), and there is a setup.cfg in that search path, coverage should look for configuration values in that file. The rational for this is simple two fold; many tools already use this file for configuration (nose, flake8 are two that I personally use that will look in this file), and this gives the option to de-pollute a repository with files that are ostensibly infrastructure configuration, rather than the task at hand: code.
I am listing this as minor as this is just a 'would be nice' kind of enhancement.
Comments (8)
-
-
As for the first point: it keeps the repo clean. I dont know if it is documented as being the intended use anywhere, but it seams that setup.cfg is used as a tooling configuration more than just a setup configuration. I like this. I like having all of my tooling configured in the same place.
I cannot give another example of a project that uses multiple sections in setup.cfg, but I can give you an example of how I would implement multiple sections - tox testenv definitions. The prefix a section name with a string ('testenv').
For example, one could prefix the string 'coverage:' to the section names, then it is as simple as stripping that string out before being handed to the existing configuration code.
-
Just to throw in my vote/$0.02. I came across this issue because I was googling to see if I could move
.coveragerc
settings intosetup.cfg
. This may be the wrong way of thinking, but many tools support this (flake8 and pytest) and I just moved some custom compliance script's we have to usesetup.cfg
as well.While it doesn't have to do with
setup.py
directly, it does have to do with our development process and it's nice to have one place to look for all project development related configuration (and to get the rest of the team to remember where to look). I'm not sure how the PyPA feels about people piggy backing onsetup.cfg
and I guess that would be interesting to know.Also, it's easy to forget about hidden files, especially team members that primarily work with other languages.
-
I'll upvote this one. I keep all my test configuration in setup.cfg and a [coverage] section would be wonderful!
@Ned Batchelder here's an example of OpenStack using setup.cfg in one of their projects https://github.com/openstack/nova/blob/master/setup.cfg
-
- changed status to resolved
Implemented in 1a0649ca2b8f
-
Is it available in the PyPI's 3.7.1 version?
-
@Fellipe Castro no, it's in the upcoming 4.0 release.
-
Cheers @Ned Batchelder,
I really appreciate it! =D
- Log in to comment
This is an interesting idea. I never quite understood why other projects piggy-backed on setup.cfg, after all, coverage settings have nothing to do with your setup.py or installation of any sort.
Also, coverage already uses sections within its .coveragerc file. Do you have any examples of projects nesting their multiple configuration sections inside setup.cfg?