Recent improvements to ERPNext contribution process

Recently we have made 2 improvements in ERPNext contribution process to streamline contributions and reduce manual work.

Automated backports

~1 month ago we started automating backports of small PRs (that can be squashed). This is done using github action: GitHub - frappe/backport: backport automation @ frappe

What this means for you(the contributor)?: less time spent on manual cherry-picking work.

Standardized linter/style checks

We have added pre-commit configuration to ensure that all commits pass a bare minimum correctness and style requirement. Currently this includes just two things:

  1. Flake8 correctness checks (all fluff non-critical issues are ignored)
  2. whitespace trimming (style)
  3. sorted imports using isort (style)

You need to do one time setup of pre-commit hooks so all your future commits will be automatically checked using current config.

$ (virtualenv) pip install pre-commit
$ (virtualenv) pre-commit install

There could be more in future :wink: like…

  1. auto-formatter - GitHub - frappe/black: Python black with tabs (depends on this change on github )
  2. semantic commit title check.

What this means for you(the contributor)?: quick feedback on trivial issues.

Just to clarify: This is NOT mandatory. You can also just set up your code editor to strip whitespace, lint code using flake8 and run isort before sending a patch…

Updated contribution guideline page: Pull Request Checklist · frappe/erpnext Wiki · GitHub


Nice, I’ve done the same and copy the configuration file for my custom app, nice to have some guidance and structuration into Frappe developpement


I’m facing a dilemma.
When I use the pre-commit of frappe/erpnext (they are not the same) on my own apps, the result is not Python Quality standard compliant. The black and flake8 parsing and fix application change space into tabs.
These “errors” are excluded on the report with .flake8 file in Frappe and .github\helpers\ .flake8_strict in ERPNext, but flake8 and iOrder seems to not be agree with some change operate by black… the check failed as everythings seems to be ok.
Is this still consistent to try to use this pre-commit hook ?
Is it used by Frappe internals teams ?
Is it compliant with github CI workflow (linter) ?
Should I drop this pre-commit and just use the IDE recommendation (they seems to match with the
Python Code Quality Authority ) on Python standard ?