CONTRIBUTING: introduce pre-commit

[xrmx]

Description

Instead of asking developers to run commands from tox manually let them configure pre-commit and run them automatically before committing (and pushing :).

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• [x] pre-commit

Does This PR Require a Contrib Repo Change?

Answer the following question based on these examples of changes that would require a Contrib Repo Change:

• The OTel specification has changed which prompted this PR to update the method interfaces of opentelemetry-api/ or opentelemetry-sdk/

• The method interfaces of test/util have changed

• Scripts in scripts/ that were copied over to the Contrib repo have changed

• Configuration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in

  • pyproject.toml
  • isort.cfg
  • .flake8

• When a new .github/CODEOWNER is added

• Major changes to project information, such as in:

  • README.md
  • CONTRIBUTING.md

• [ ] Yes. - Link to PR:

• [x] No.

Checklist:

• [ ] Followed the style guidelines of this project
• [ ] Changelogs have been updated
• [ ] Unit tests have been added
• [x] Documentation has been updated

[lzchen]

Im not too familiar with pre-commit. What happens after user installs pre-commit install? Do they need to run anything else?

[xrmx]

Im not too familiar with pre-commit. What happens after user installs pre-commit install? Do they need to run anything else?

pre-commit will configure git hooks to run the tools before committing so if any of the tool will fail code will be fixed automatically (for black at least) but not committed. The idea is to catch the low hanging fruit issues (black, flake8 and isort) before pushing to github.

[lzchen]

Im not too familiar with pre-commit. What happens after user installs pre-commit install? Do they need to run anything else?

pre-commit will configure git hooks to run the tools before committing so if any of the tool will fail code will be fixed automatically (for black at least) but not committed. The idea is to catch the low hanging fruit issues (black, flake8 and isort) before pushing to github.

So the git hooks will be run when user chooses to git commit? Also curious if the commands will pick up the linting configuration we have for black, flake8 and isort in .flake8 and .isort.cfg and such.

[xrmx]

pre-commit will configure git hooks to run the tools before committing so if any of the tool will fail code will be fixed automatically (for black at least) but not committed. The idea is to catch the low hanging fruit issues (black, flake8 and isort) before pushing to github.

So the git hooks will be run when user chooses to git commit? Also curious if the commands will pick up the linting configuration we have for black, flake8 and isort in .flake8 and .isort.cfg and such.

yes, black and the linters will run when git commit is invoked. The configuration files we ship in the repo will be used since they are in the root of the project dir.

[emdneto]

@xrmx Did some tests and it's working fine:

git commit -m "test"

black....................................................................Failed
- hook id: black
- files were modified by this hook

reformatted test.py

All done! ✨ 🍰 ✨
1 file reformatted.

isort....................................................................Passed
flake8...................................................................Passed

Do you think it will be worth to have pre-commit in dev-requirements?

[xrmx]

@emdneto I have pre-commit installed globally but yeah, could make sense to have it in dev-requirements.