Attempt to get configuration from setup.cfg if .coveragerc is not present

[nedbat]

Originally reported by Alexander Walters (Bitbucket: sdamon, GitHub: sdamon)

---

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.

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/304

[nedbat]

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?

[nedbat]

Original comment by Alexander Walters (Bitbucket: sdamon, GitHub: sdamon)

---

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.

[nedbat]

Original comment by Mark M Evans (Bitbucket: markmevans, GitHub: markmevans)

---

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 into setup.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 use setup.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 on setup.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.

[nedbat]

Original comment by Micah Hausler (Bitbucket: micahhausler, GitHub: micahhausler)

---

I'll upvote this one. I keep all my test configuration in setup.cfg and a [coverage] section would be wonderful!

@nedbat here's an example of OpenStack using setup.cfg in one of their projects https://github.com/openstack/nova/blob/master/setup.cfg

[nedbat]

Implemented in 1a0649ca2b8f (bb)

[nedbat]

Original comment by Fellipe Castro (Bitbucket: fellipecastro, GitHub: fellipecastro)

---

Is it available in the PyPI's 3.7.1 version?

[nedbat]

@FellipeCastro no, it's in the upcoming 4.0 release.

[nedbat]

Original comment by Fellipe Castro (Bitbucket: fellipecastro, GitHub: fellipecastro)

---

Cheers @nedbat,

I really appreciate it! =D