pyupgrade (for the ones that are Python 3+ only)Īnd add more tooling as we agree on, like:.If there is enough consensus ( framework team? should I write a PLIP?) I would volunteer to do a friendly fork of that repository to the plone (maybe collective as well) organization, and start configuring repositories with it.Īs a wishlist one could start with the uncontroversial ones:

This repository has a set of scripts and configuration files that allow to mass-configure and for that unify configuration files, CI workflows and what not no fancy f-strings for you ).Īgain, others came up with a solution the zope folks ( ) came up with meta (not related to Facebook as far as I know ). That's where the enforcing part comes into play.įor a while GitHub Actions are the new rage in CI, so let's use them for itĬonfiguring a single repository is not that hard, see this example PR on plone.batching, but things start getting complex when you try to lint a package that has to be still Plone 5.2 compatible, and thus maintain python 2.7 compatibility (i.e. Unfortunately the next contributor might miss to use these tools, so we are back to square one Not all developers are native English speakers, and even so, we all make typos on our mother tongues So yet more tooling to help out ( codespell).Īll these tools are great and if you do your duty of linting a package with all of them and on top of that add some extra functionality, you are already a hero With python, and Plone following, moving to python 3 and a year release cadence, new syntax is coming and old one is deprecated, so more tooling ( pyupgrade and plenty others) have became sort of standards to ease upgrading the syntax. Out of plone.api came a Plone styleguide that eventually was tried to be enforced by .įrom there plenty of flake8 plugins were born.īlack has rendered any formatting discussion moot (for good ).

The ones that know me already know that I have a slight OCD on linting

Jenkins black formatter