Introduce coding standards enforcement

[arturponinski]

Overview

There is a number of mature tools that could, or even should be used to enforce coding standards for the code base.

The tools to consider are:

• pyupgrade
• flake8
• black
• isort
  The configuration for those tools should be set up in the repository.

Task list

• agree on tools to use and their configuration
• add a separate requirements file
• add a pre-commit hook that can be used by contributors
• add github action that will verify if the PR conforms the standards
• update contributing section of the docs

Since this will affect whole codebase, it should be considered for 2.0 release

[juarezr]

I agree.

Additionally, we should consider:

• pre-commit hooks (format, check ) in sync with CI ( check )
• Auto format on save ( IDE, vscode, ... )
• Unifying configuration in pyproject.toml
• Reformat all code in one shot
• Blocking PR on formatting / linting issues ( Codacity, CodeQL checks )

[arturponinski]

I had a second though about this and was wondering about such an approach:

• prepare and configure the tools that should be used still for versions 1.*
• reformat the whole code and release version 1.8.0 which would be the last supported, and let's say only critical bugs would be fixed til end of 2022
• from this point start branch 2.0

This would give us the opportunity to easily compare differences between 1.* and 2.* and in case of any bugs the necessary changes would be much easier to apply to both versions

[juarezr]

• Interesting approach. Looks pretty good to me.
• My 2 cents:
  • The only thing that we need to pay attention to is breaking compatibility.
    • Ideally, we should batch all compatibility breaking changes in v2.0
    • But as we are volunteers, we can postpone anything beyond our availability
    • As everything is working, we don't have a strong reason to tag a v2.0 right now.
    • Maybe typing would be such a killer feature to drop compatibility...
  • Using a formatted v1.8.x in parallel with a non-release v2.0.x branch would be amazing
  • Similarly, we can do v1.9.x as bug fix releases after we release v2.0.x

[juarezr]

@arturponinski ,

Alter #613 I started wondering if:

• There are other places in the source code that would benefit from compliance with PEP 479
• There are other PEP-XXX modernization efforts that would benefit petl
• Should we keep track of these kinds of improvements