Different Python versions in monorepo

[andreas-vester]

I am thinking abouit moving to a monorepo structure.

I have a couple of libraries/projects that require different Python versions (3.12 all the way down to 3.9). I am wondering if/how I can use different Python versions in a monorepo?

I can declare the requires-python part in every individual pyproject.toml file in my libraries/projects accordingly. But isn't this related to have dedicated .venv for every project? How is this going to work?

[kokoc30]

Yes—keep the projects as independent PDM projects inside the same Git repository. Each project can have its own pyproject.toml, lock file, selected interpreter and virtual environment. The repository itself does not have to use one Python version.

For example, assuming packages/legacy and packages/modern already contain their own pyproject.toml files and the requested Python interpreters are installed:

pdm use -p packages/legacy 3.9
pdm install -p packages/legacy
pdm run -p packages/legacy python -V

pdm use -p packages/modern 3.12
pdm install -p packages/modern
pdm run -p packages/modern python -V

With PDM 2.13+ and the default python.use_venv = true / venv.in_project = true settings, selecting an interpreter this way creates or reuses a project virtual environment. The two environments live at packages/legacy/.venv and packages/modern/.venv; each project's .pdm-python records its selected interpreter. Run this setup without another project's virtual environment activated. If you have changed those defaults, set them with pdm config -p <project-path> --local python.use_venv true and pdm config -p <project-path> --local venv.in_project true.

requires-python describes which Python versions a project supports; it does not select the interpreter. For instance, >=3.9 also allows 3.12. Use pdm use to choose the actual interpreter, and pdm run to execute in that project's environment without activating it manually.

One version-specific distinction: PDM 2.28+ also has experimental workspaces. Workspace members share the root environment and lock file, so a single workspace is a different setup from the independent environments described above. For projects that actually need different runtimes, keep them independent rather than registering them as members of one workspace.

References: virtual environments, CLI options, workspace environment sharing.