Gil Forcada: meta and robots for a better developer experience

Who is here in Plone 20 years from now? We have a scale problem. People come and go, but Plone stays.

PEP420: Python native namespaces. You already get warnings when you still use other (setuptools) namespaces. Tricky to combine both in one namespace. It is best to switch in one day. We use about 100 Zope packages, 100 Plone packages, there are 200 or more collective packages, you may have internal namespaces.

How do we pass on knowledge? Can anyone here in the room make a Plone release if Maurits goes on vacation? There is documentation, training, a World Plone Day video of Maurits releasing Plone.

We can talk a lot to share knowledge, but we should also codify this knowledge. Create a predictable Developer Experience (DX). You work on a bugfix in a package, and do not need to worry if CI (continuous integration) is working, or wonder how to run the tests locally.

If you use an approach in one package and need to manually copy this approach to all other Plone packages, you will get tired, and make mistakes. If no check is done at every commit or PR, then you end up making several cleanup commits, fixing black/isort issues.

We have a long history of tools we use for checking code quality, including Jenkins, mr.roboto, GitHub Actions. When you create a patch in a PR, as occasional developer or big-time core Plone developer, the same checks should be run. Can you check this before you push a change? Yes.

How can you know if your add-on works? You write tests and run these automatically. Does your shiny new add-on still works after a few days when you have merged your own PR? Or after a few weeks when another developer creates a PR? Or a few months, after some dependencies get security releases? After a few years when there are new Plone and Python versions?

Introducing plone/meta, see https://github.com/plone/meta/. Original idea from https://github.com/zopefoundation/meta/. These are some templates for how you write setup.py, setup.cfg, pyproject.toml, GitHub action files, etc. It includes a tool you can point at a directory with your add-on, or a core Plone package, and apply the standards. Then run for example tox -e test to run the tests.

It also configures a tool for checking cyclic dependencies. When a cyclic dependency is discovered, you fix it. And because the check is done automatically, we guard against regressions, where cyclic dependencies would inadvertently be reintroduced.

It has various linters, formatters, a spell checker, check for release readiness.

Its main goal is for Plone packages, but you can use it for collective packages and packages from your company.

What is next? It would be good to test across different Plone and Python versions. Test ClassicUI and REST API.

Other ideas: plonecli/cookiecutter integration would be nice, so you get this configuration in new projects that you create. Create a local Plone instance with the add-on. Auto-update.

What is the power within? We use tox, but that is an implementation detail, could be nox, docker, containers, make.

Contributors are welcome: test it, use it, add fixes and features.

Questions? It would be good to support tests for frontend and backend, where the code is in sub directories instead of the top level folder. In the Zope meta repo there are already different skeletons, because they have normal Python packages, but also packages with C code which need different files and settings.