Plone codebases in 2025

(Or why I’m getting tired of managing 150 add ons and projects at the same time)
In this presentation I share the challenges and (possible) solutions for managing Plone codebases -- projects, distributions, add-ons -- in 2025.

Transcript

1. Érico Andrei | https://ericof.com | @ericof@pynews.com.br | @ericof.com | @ericof Plone codebases in 2025 Or why I’m getting tired of managing 150 add ons and projects at the same time
2. First a request
3. @plonegovbr/volto-code-block https://github.com/plonegovbr/volto-code-block • Who uses this package: • Victor, me, plone.org.br … • What • Uses https://prismjs.com/ • Needs to be moved to https://shiki.style/ • Reasons: • PrismJS is “dead" • Current implementation is hard to extend (add new languages) • Shiki is not “dead"
4. @plonegovbr/volto-code-block https://github.com/plonegovbr/volto-code-block • Challenges • I’m not a frontend developer :-) • There is async code involved somewhere, somehow • Have code highlighting while you edit the block • (This “works" today with Prism) • I’m not a frontend developer :-) • Prize • Beers (or co ff ee)
5. A Plone codebase could be …
6. A distribution Your own CMS • A distribution is a CMS based on top of Products.CMFPlone • We could say Plone is the new CMF • It should control the dependencies constraints — like Plone does — after all, it is a CMS and you should have versions, upgrades, etc, etc • Headless or not? • Classic-based • plone.restapi • Some examples • plone.classicui • plone.volto (Volto) • kitconcept.intranet • portalbrasil.* (plonegovbr/portabrasl-intranet)
7. Project Install Plone* somewhere • A project is a CMS project, based on an existing distribution, to solve somebody’s problem • It should have a tighter control on all dependencies used: Products.CMFPlone == 6.1.1, @plone/volto == 18.10.1 • Based on Classic • A Python “policy package” that will “bend" Plone to your will • Docs • CI / CD / Deployment con fi guration • Based on Volto (Mono repo) • Backend: A Python “policy package” that will “bend" Plone to your needs • Frontend: A Node “policy package” to "bend" Volto to your needs • Docs • CI / CD / Deployment con fi guration
8. An Add On Features to Plone / Volto that can be shared between projects • A package containing code to implement new features for Plone, Volto, or both • Usually it will be published to PyPi / NPM • It needs to run (and be tested) on a matrix of versions of Python / Plone / Node / Volto • It can be: • Just Python code: ✅ (pas.plugins.oidc, pas.plugins.authomatic) • Just Node code: ✅ (@plonegovbr/volto-code-block, @eea/*) • Python + Node: ❗ • volto-form-support / collective.voltoformsupport • @plone-collective/volto-bookmarks / collective.bookmarks • @kitconcept/volto-light-theme / kitconcept.voltolighttheme
9. Requirements
10. Distribution & Projects Control what you “require" • Explicitly target one version of Python / Node • Always pin exact versions for important dependencies on (setup.py, pyproject.toml, package.json) • Products.CMFPlone == 6.1.1 (instead of Products.CMFPlone) • Maintain its own list of constraints • In the old buildout days we had that with versions.cfg • Testing: • Speci fi c Python / Plone • Speci fi c Node / Volto
11. Add ons Focus on compatibility • Explicitly state which versions you support • Python: Trove classi fi ers / python_requires • Node: Peer dependencies? • Testing • Matrix of all supported versions
12. Opinions
13. Python packaging is a nightmare But it seems we have a path • First, move to pyproject.toml • setup.py, setup.cfg -> pyproject.toml • Move away from setuptools • Unless you have an existing project that for any reason requires it • Build: setuptools -> hatchling • Namespaces: pkg_resources -> pkgutil • Python / Project management • Python env: pyenv, brew, installers -> UV • Package installations: pip -> uv (either uv pip or simply uv)
14. Mono repo rulez Project, Distribution or Add on • If you require / need / want to have backend and frontend code => mono repo • Uni fi ed releases: • Both components will always have the same version number • Pros: • Easy to test • Easy to maintain • Reduced overhead • Cons: • Our current toolset is not prepared for this
15. Toolset
16. cookieplone-templates Using the new shiny (stable) things 1/3 • Backend Add on • uv based • Installation via uv pip install • pyproject.toml (No more setup.py): • Build: hatchling • [tool.uv]: managed = false • Supports an environment variable PLONE_VERSION to download / install the version you want • mxdev: Generated fi les are on .gitignore (also requirements.txt) • Version in the __init__.py of the package (PEP440) • Change log with towncrier • GHA work fl ow tests the matrix of Python x Plone versions
17. cookieplone-templates Using the new shiny (stable) things 2/3 • Frontend Add on • Uses package-centric approach • Change log with towncrier • Version in the package.json of the add on package (SemVer) • GHA work fl ow only testing on speci fi c Volto version (this need to be changed)
18. cookieplone-templates Using the new shiny (stable) things 3/3 • Project • Focus on project, not publishable on PyPi / NPM • 3 change log locations: root, backend, frontend • To keep track of all changes, and package changes • repository.toml con fi g • Talk about that later • version.txt with project version (PEP440)
19. plone-repo-helper github.com/kitconcept/plone-repo-helper • Uses repository,toml con fi g and leverages existing tools (towncrier, mxdev) • Dependency management for backend packages managed by uv • uv run repo deps plone 6.1.1 • Updates Products.CMFPlone version in [project.dependencies] • Updates [tool.uv.constraints] with list from dist.plone.org • Uni fi ed mono repo release (github.com/plonegovbr/br fi eldsandwidgets) • uv run repo changelog • uv run repo release do 1.0.0a1 • Update root: CHANGELOG.md, version.txt, docker-compose.yml • Release backend package (plonegovbr.br fi elds) to PyPi • Release frontend package (@plonegovbr/volto-brwidgest) to NPM • Create new tag, pushes to origin WIP
20. plone-repo-helper WIP, but already in use • Distribution: github.com/kitconcept/kitconcept.intranet • Speci fi c Products.CMFPlone version • Add on: github.com/plonegovbr/br fi eldsandwidgets • Matrix of versions • Add on: github.com/kitconcept/volto-light-theme • Matrix of versions • Project: Internal Simples Consultoria project • Speci fi c Products.CMFPlone version • No publishing to NPM / PyPi WIP
21. Next steps
22. cookieplone-templates Start versioning the templates • version.txt on repo root • Change log with towncrier
23. cookieplone-templates Add 2 new templates • New templates based on mono repo Project • Distribution • Already with correct trove classi fi er • distributions.zcml • distributions/ • Frontend / Backend Add on • Add on with backend and frontend packages
24. plone-repo-helper Initial release • Move to github.com/plone/plone-repo-helper • Publish initial version on PyPi • Usage will be • uvx —from ‘plone-repo-helper’ repo <command> • What else: • Handle dependencies other than Products.CMFPlone (plone.volto, kitconcept.intranet)
25. GHA Add shared actions / work fl ows to plone/meta • Add to plone/meta • Composite actions to setup Python, setup Node, build container images • Shared work fl ows for Backend lint / test, Frontend lint / test / i18n • New shared work fl ows on Tag push • NPM: build and publish package • PyPi: build and publish package (recommended way by PyPA)
26. /ericof @ericof @ericof@pynews.com.br @ericof.com