Overview

Build tools will be located by reading a file pypa.json from the root directory of the source tree. That file describes how to get the build tool and the name of the command to run to invoke the tool.

All tools will be expected to conform to a single command line interface modelled on pip's existing use of the setuptools setup.py interface.

pypa.json

The file pypa.json acts as a neutral configuration file for pip and other tools that want to build source trees to consult for configuration. The absence of a pypa.json file in a Python source tree implies a setuptools or setuptools compatible build system.

The JSON has the following schema. Extra keys are ignored, which permits the use of pypa.json as a configuration file for other related tools. If doing that the chosen keys must be namespaced under tools:

{"tools": {"flit": ["Flits content here"]}}

schema

The version of the schema. This PEP defines version "1". Defaults to "1" when absent. All tools reading the file must error on an unrecognised schema version.

bootstrap_requires

Optional list of dependency specifications [#pep508] that must be installed before running the build tool. For instance, if using flit, then the requirements might be:

bootstrap_requires: ["flit"]

build_command

A mandatory key, this is a list of Python format strings [10] describing the command to run. For instance, if using flit then the build command might be:

build_command: ["flit"]

If using a command which is a runnable module fred:

build_command: ["{PYTHON}", "-m", "fred"]

Process interface

The command to run is defined by a simple Python format string [10].

This permits build systems with dedicated scripts and those that are invoked using "python -m somemodule".

Processes will be run with the current working directory set to the root of the source tree.

When run, processes should not read from stdin - while pip currently runs build systems with stdin connected to it's own stdin, stdout and stderr are redirected and no communication with the user is possible.

As usual with processes, a non-zero exit status indicates an error.

Available format variables

PYTHON

The Python interpreter in use. This is important to enable calling things which are just Python entry points.

{PYTHON} -m foo

Available environment variables

These variables are set by the caller of the build system and will always be available.

PATH

The standard system path.

PYTHON

As for format variables.

PYTHONPATH

Used to control sys.path per the normal Python mechanisms.

Subcommands

There are a number of separate subcommands that build systems must support. The examples below use a build_command of flit for illustrative purposes.

build_requires

Query build requirements. Build requirements are returned as a UTF-8 encoded JSON document with one key build_requires consisting of a list of dependency specifications [12]. Additional keys must be ignored. The build_requires command is the only command run without setting up a build environment.

Example command:

flit build_requires

metadata

Query project metadata. The metadata and only the metadata should be output on stdout in UTF-8 encoding. pip would run metadata just once to determine what other packages need to be downloaded and installed. The metadata is output as a wheel METADATA file per PEP-427 [7].

Note that the metadata generated by the metadata command, and the metadata present in a generated wheel must be identical.

Example command:

flit metadata

wheel -d OUTPUT_DIR

Command to run to build a wheel of the project. OUTPUT_DIR will point to an existing directory where the wheel should be output. Stdout and stderr have no semantic meaning. Only one file should be output - if more are output then pip would pick an arbitrary one to consume.

Example command:

flit wheel -d /tmp/pip-build_1234

develop [--prefix PREFIX]

Command to do an in-place 'development' installation of the project. Stdout and stderr have no semantic meaning.

Not all build systems will be able to perform develop installs. If a build system cannot do develop installs, then it should error when run. Note that doing so will cause use operations like pip install -e foo to fail.

The prefix option is used for defining an alternative prefix for the installation. While setuptools has --root and --user options, they can be done equivalently using --prefix, and pip or other tools that accept --root or --user options should translate appropriately.

The root option is used to define an alternative root within which the command should operate.

For instance:

flit develop --root /tmp/ --prefix /usr/local

Should install scripts within /tmp/usr/local/bin, even if the Python environment in use reports that the sys.prefix is /usr/ which would lead to using /tmp/usr/bin/. Similar logic applies for package files etc.

The build environment

Except for the build_requires command, all commands are run within a build environment. No specific implementation is required, but a build environment must achieve the following requirements.

1. All dependencies specified by the project's build_requires must be available for import from within $PYTHON.

1. All command-line scripts provided by the build-required packages must be present in $PATH.

A corollary of this is that build systems cannot assume access to any Python package that is not declared as a build_requires or in the Python standard library.

Hermetic builds

This specification does not prescribe whether builds should be hermetic or not. Existing build tools like setuptools will use installed versions of build time requirements (e.g. setuptools_scm) and only install other versions on version conflicts or missing dependencies. However its likely that better consistency can be created by always isolation builds and using only the specified dependencies.

However there are nuanced problems there - such as how can users force the avoidance of a bad version of a build requirement which meets some packages dependencies. Future PEPs may tackle this problem, but it is not currently in scope - it does not affect the metadata required to coordinate between build systems and things that need to do builds, and thus is not PEP material.

Upgrades

'pypa.json' is versioned to permit future changes without requiring compatibility.

The sequence for upgrading either of schemas in a new PEP will be:

1. Issue new PEP defining an updated schema. If the schema is not entirely backward compatible then a new version number must be defined.
2. Consumers (e.g. pip) implement support for the new schema version.
3. Package authors opt into the new schema when they are happy to introduce a dependency on the version of 'pip' (and potentially other consumers) that introduced support for the new schema version.

The same process will take place for the initial deployment of this PEP:- the propogation of the capability to use this PEP without a setuptools shim will be largely gated by the adoption rate of the first version of pip that supports it.

Static metadata in sdists

This PEP does not tackle the current inability to trust static metadata in sdists. That is a separate problem to identifying and consuming the build system that is in use in a source tree, whether it came from an sdist or not.

Handling of compiler options

Handling of different compiler options is out of scope for this specification.

pip currently handles compiler options by appending user supplied strings to the command line it runs when running setuptools. This approach is sufficient to work with the build system interface defined in this PEP, with the exception that globally specified options will stop working globally as different build systems evolve. That problem can be solved in pip (or conda or other installers) without affecting interoperability.

In the long term, wheels should be able to express the difference between wheels built with one compiler or options vs another, and that is PEP material.

Network effects

Projects that adopt build systems that are not setuptools compatible - that is that they have no setup.py, or the setup.py doesn't accept commands that existing tools try to use - will not be installable by those existing tools.

Where those projects are used by other projects, this effect will cascade.

In particular, because pip does not handle setup-requires today, any project (A) that adopts a setuptools-incompatible build system and is consumed as a setup-requirement by a second project (B) which has not itself transitioned to having a pypa.json will make B uninstallable by any version of pip. This is because setup.py in B will trigger easy-install when 'setup.py egg_info' is run by pip, and that will try and fail to install A.

As such we recommend that tools which are currently used as setup-requires either ensure that they keep a setuptools shim or find their consumers and get them all to upgrade to the use of a pypa.json in advance of moving themselves. Pragmatically that is impossible, so the advice is to keep a setuptools shim indefinitely - both for projects like pbr, setuptools_scm and also projects like numpy.

setuptools shim

It would be possible to write a generic setuptools shim that looks like setup.py and under the hood uses pypa.json to drive the builds. This is not needed for pip to use the system, but would allow package authors to use the new features while still retaining compatibility with older pip versions.