Introduce coding standards enforcement

petl-developers / petl

Python Extract Transform and Load Tables of Data

MIT License

1.22k stars 190 forks source link

Introduce coding standards enforcement #597

Open arturponinski opened 2 years ago

arturponinski commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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