Add black formatter

[Spacetown]

• Move configuration for coverage from setup.cfg to pyproject.toml.
• Switch from flake8 to flake9 (Fork which supports pytoml.xml) and update documentation.
• Add configuration for black to format code.
  • Pro:
    • I used it in another project and the formatted code looks good for me.
    • Formatting of code is independand of the developer and looks the same in the whole project.
    • No need of configuration.
• Contra:
  • No configuration possible.

[codecov]

Codecov Report

Merging #444 (a4b5697) into master (136b154) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #444   +/-   ##
=======================================
  Coverage   95.52%   95.52%           
=======================================
  Files          20       20           
  Lines        2458     2458           
  Branches      420      420           
=======================================
  Hits         2348     2348           
  Misses         48       48           
  Partials       62       62           

Flag	Coverage Δ
ubuntu-18.04	95.03% <ø> (ø)
windows-2019	95.11% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 136b154...a4b5697. Read the comment docs.

[latk]

After thinking about this for a bit, I'm not quite sure this is a step in the right direction.

• creating a pyproject.toml? Probably fine, though I don't see the value yet. Yes, Toml is a better format than Ini, but just moving configuration around doesn't necessarily improve much.
• using flake9? That looks like an incompatible fork that could cause problems if a first-time contributor wants to work on gcovr without a virtualenv, and who already has flake8 installed. If we want to move flake8 configuration into a config file, then setup.cfg would seem like the appropriate target.
• the black formatter is totally fine, as long as it won't change the current code (otherwise, a commit that re-formats the code would be appropriate). If this tool is supposed to be part of the development workflow, then adding it as a dependency would be appropriate.
• I don't quite see why requirements files are a problem. They are widely supported in the PIP ecosystem and easy to use. Our dependency lists don't have to be generated by code.

Of course I'm willing to be convinced otherwise. There are two very good aspects in this PR that I'd like to keep though: specifying a code formatter, and simplifying invocation of flake8 by using a config file.

[Spacetown]

• creating a pyproject.toml? Probably fine, though I don't see the value yet. Yes, Toml is a better format than Ini, but just moving configuration around doesn't necessarily improve much.

• using flake9? That looks like an incompatible fork that could cause problems if a first-time contributor wants to work on gcovr without a virtualenv, and who already has flake8 installed. If we want to move flake8 configuration into a config file, then setup.cfg would seem like the appropriate target.

Flake9 only because flake8 doesn't support pyproject.toml. I thought one configuration to configure all tools would be fine. I think it will be better to document onla that flake8 is used and the options are fixed in a configuration (maybe setup.py).

• the black formatter is totally fine, as long as it won't change the current code (otherwise, a commit that re-formats the code would be appropriate). If this tool is supposed to be part of the development workflow, then adding it as a dependency would be appropriate.

If we start to use black it should be added to the tests and a reformat of all files is needed one time.

* I don't quite see why requirements files are a problem. They are widely supported in the PIP ecosystem and easy to use. Our dependency lists don't have to be generated by code.

The runtime requirements are configured in setup.py, the development requirements in requirements.txt and the documentation requirements in doc/requirements.txt. I think, a single place to specify all requirements is better.

Of course I'm willing to be convinced otherwise. There are two very good aspects in this PR that I'd like to keep though: specifying a code formatter, and simplifying invocation of flake8 by using a config file.

The simplifying of the invocation is a big advantage.

[Spacetown]

@latk I've revert the pyproject.toml, moved the configuration of flake8 to setup.cfg and introduced black.
The errorlevel of black is ignored at the moment because I don't want to reformat all the source files. This can be done if the file is changed.

[latk]

Looks good! Just two minor inline comments below.

For future reference, updating the title might also be a good idea.

Unfortunately, reformatting all code will lead to substantial merge conflicts. So we should probably delay that step for a bit until fewer PRs are still pending. So it's good that the CI failure is ignored (for now).