Package management

Package management#

Plone 6 consists of a collection of Python and Node.js packages. Over the decades of its existence, Plone has used several package management tools, sometimes multiple tools at one time. Each one has its strengths and weaknesses for performing specific tasks, such as installation, conflict resolution, updates, upgrades, and working with virtual environments and across platforms.

With Volto as the default frontend in Plone 6, first npm, then pnpm, was brought into the mix as a package manager for its Node.js packages.

Python itself has a complex and convoluted history with package management, as xkcd illustrates.

A comic from xkcd entitled Python Environment

Manage backend Python packages#

uv, pip with mxdev, and buildout are supported tools to manage the Python packages in the Plone backend. The following sections explain each of these tools in more detail.

uv#

uv is a package manager which is popular for its speed, its ability to manage the installation of Python itself, and its ability to consistently reproduce installed packages using a uv.lock file.

When a project is fully managed using uv, it is configured in its pyproject.toml file, and its packages are installed using uv sync.

uv also has a pip interface, and installs packages into a virtual environment via the command uv pip install.

If you create a Plone project using Cookieplone, it creates a backend managed by uv.

pip#

By convention in the Python community, pip is commonly used to install Python packages. It is one supported way to install the Plone backend.

Each Plone version requires specific versions of many different packages. So, pip should be used with constraints to make sure the correct versions are installed. For example:

bin/pip install -c https://dist.plone.org/release/6.1-latest/constraints.txt Plone

In the Plone community, constraints are sometimes called "version pins."

As a best practice, pip should always be used inside a specific Python virtual environment to keep the packages separate from other applications.

mxdev#

During development, it is sometimes necessary to override the Plone version constraints. This makes it possible to:

pip does not allow overriding constraints this way. mxdev solves this issue.

mxdev resolves Plone constraints according to your needs for pinning versions or source checkouts. It reads its configuration file mx.ini, and your requirements.txt and constraints.txt files. Then it fetches the requirements and constraints of Plone. Finally, it writes new combined requirements in requirements-mxdev.txt and new constraints in constraints-mxdev.txt. Together these two files contain the combined requirements and constraints, but modified according to the configuration in mx.ini. The generated files indicate from where the constraints were fetched, and comments are added when a modification was necessary.

mxdev does not run pip or install packages. You or your development tools, such as GNU Make, must perform that step.

buildout#

Buildout is a tool for installing Python packages that has been used in the Plone community since about 2007, and is still preferred by some members of the community.

It not only installs packages, but can set up other things using an extensible system of "recipes."

Buildout does not install Python packages into a virtual environment. Instead, it creates scripts that add the necessary packages to sys.path before running the script target.

Manage frontend Node.js packages#

Plone uses pnpm to install Node.js packages.

Compared to the standard npm, it has features that help with developing multiple Node.js packages in the same workspace. In Plone, this is used to manage the installation of your project add-on alongside Volto core and other add-ons.