Contents

• Abstract
• Motivation
• Rationale
• Terminology and goals
• The Mechanism
  • get_requires_for_build_editable
  • prepare_metadata_for_build_editable
  • build_editable
  • Build frontend requirements
  • Frontend requirements
  • Example editable implementations
    • Add the source tree as is to the interpreter
    • Using custom importers
• Rejected ideas
• References
• Copyright

Abstract

This document describes extensions to the build backend and frontend communication (as introduced by PEP 517) to allow projects to be installed in editable mode by introducing virtual wheels.

Motivation

During development, many Python users prefer to install their libraries so that changes to the underlying source code and resources are automatically reflected in subsequent interpreter invocations without an additional installation step. This mode is usually called “development mode” or “editable installs”. Currently, there is no standardized way to accomplish this, as it was explicitly left out of PEP 517 due to the complexity of the actual observed behaviors.

At the moment, users to get this behaviour perform one of the following:

• For just Python code by adding the relevant source directories to sys.path (configurable from the command line interface via the PYTHONPATH environment variable). Note in this case, the users have to install the project dependencies themselves, and entry points or project metadata are not generated.
• setuptools 7 provides the setup.py develop 6 mechanism: that installs a pth file that injects the project root onto the sys.path at interpreter startup time, generates the project metadata, and also installs project dependencies. pip 5 exposes calling this mechanism via the pip install -e command-line interface.
• flit 3 provides the flit install –symlink 4 command that symlinks the project files into the interpreters purelib folder, generates the project metadata, and also installs dependencies. Note, this allows supporting resource files too.

As these examples shows an editable install can be achieved in multiple ways and at the moment there’s no standard way of doing it. Furthermore, it’s not clear whose responsibility it is to achieve and define what an editable installation is:

1. allow the build backend to define and materialize it,
2. allow the build frontend to define and materialize it,
3. explicitly define and standardize one method from the possible options.

The author of this PEP believes there’s no one size fits all solution here, each method of achieving editable effect has its pros and cons. Therefore this PEP rejects option three as it’s unlikely for the community to agree on a single solution. Furthermore, question remains as to whether the frontend or the build backend should own this responsibility. PEP 660 proposes the build backend to own this, while the current PEP proposes primarily the frontend, but still allows the backend to take take control if it wants to do so.

Rationale

PEP 517 deferred “Editable installs” because this would have delayed further its adoption, and there wasn’t an agreement on how editable installs should be achieved. Due to the popularity of the setuptools 7 and pip 5 projects, the status quo prevailed, and the backend could achieve editable mode by providing a setup.py develop implementation, which the user could trigger via pip install -e. By defining an editable interface between the build backend and frontend, we can eliminate the setup.py file and their current communication method.

Terminology and goals

This PEP aims to delineate the frontend and the backend roles clearly and give the developers of each the maximum ability to provide valuable features to their users. In this proposal, the backend’s role is to prepare the project for an editable installation, and then provide enough information to the frontend so that the frontend can manifest and enforce the editable installation.

The information the backend provides to the frontend is a wheel that follows the existing specification within PEP 427. The wheel metadata about the archive itself ({distribution}-{version}.dist-info/WHEEL) must also contain the key Editable with value of true.

However, instead of providing the project files within the wheel, it must provide an editable.json file (at the root level of the wheel) that defines the files to be exposed by the frontend. The content of this file is formulated as a mapping of absolute source tree paths to relative target interpreter destination paths within a scheme mapping.

A wheel that satisfies the previous two paragraphs is a virtual wheel. The frontend’s role is to take the virtual wheel and install the project in editable mode. The way it achieves this is entirely up to the frontend and is considered implementation detail.

The editable installation mode implies that the source code of the project being installed is available in a local directory. Once the project is installed in editable mode, some changes to the project code in the local source tree will become effective without the need for a new installation step. At a minimum, changes to the text of non-generated files that existed at the installation time should be reflected upon the subsequent import of the package.

Some kinds of changes, such as adding or modifying entry points or new dependencies, require a new installation step to become effective. These changes are typically made in build backend configuration files (such as pyproject.toml). This requirement is consistent with the general user expectation that such modifications will only become effective after re-installation.

While users expect editable installations to behave identically to standard installations, this may not always be possible and may be in tension with other user expectations. Depending on how a frontend implements the editable mode, some differences may be visible, such as the presence of additional files (compared to a typical installation), either in the source tree or the interpreter’s installation path.

Frontends should seek to minimize differences between the behavior of editable and standard installations and document known differences.

For reference, a non-editable installation works as follows:

1. The developer is using a tool, we’ll call it here the frontend, to drive the project development (e.g., pip 5). When the user wants to trigger a package build and installation of a project, they’ll communicate with the frontend.
2. The frontend uses a build frontend to trigger the build of a wheel (e.g., build 1). The build frontend uses PEP 517 to communicate with the build backend (e.g. setuptools 7) - with the build backend installed into a PEP 518 environment. Once invoked, the backend returns a wheel.
3. The frontend takes the wheel and feeds it to an installer (e.g.,`installer`_) to install the wheel into the target Python interpreter.

The Mechanism

This PEP adds two optional hooks to the PEP 517 backend interface. One of the hooks is used to specify the build dependencies of an editable install. The other hook returns the necessary information via the build frontend the frontend needs to create an editable install.

def get_requires_for_build_editable(config_settings=None):
    ...

def prepare_metadata_for_build_editable(metadata_directory, config_settings=None):
    ...

def build_editable(self, wheel_directory, config_settings=None,
                    metadata_directory=None):
    ...

{
  "$schema": "http://json-schema.org/draft-07/schema",
  "$id": "http://pypa.io/editables.json",
  "type": "object",
  "title": "Virtual wheel editable schema.",
  "required": ["version", "scheme"],
  "properties": {
    "version": {
      "$id": "#/properties/version",
      "type": "integer",
      "minimum": 1,
      "maximum": 1,
      "title": "The version of the schema."
    },
    "scheme": {
      "$id": "#/properties/scheme",
      "type": "object",
      "title": "Files to expose.",
      "required": ["purelib", "platlib", "data", "headers", "scripts"],
      "properties": {
        "purelib": { "$ref": "#/$defs/mapping" },
        "platlib": { "$ref": "#/$defs/mapping" },
        "data": { "$ref": "#/$defs/mapping" },
        "headers": { "$ref": "#/$defs/mapping" },
        "scripts": { "$ref": "#/$defs/mapping" }
      },
      "additionalProperties": true
    }
  },
  "additionalProperties": true,
  "$defs": {
    "mapping": {
      "type": "object",
      "description": "A mapping of source to target paths. The source is absolute path, the destination is relative path.",
      "additionalProperties": true
    }
  }
}

{
   "version": 1,
   "scheme": {
      "purelib": {"/src/tree/a.py": "tree/a.py"},
      "platlib": {},
      "data": {"/src/tree/py.typed": "tree/py.typed"},
      "headers": {},
      "scripts": {}
   }
}

{
  {"version": 1, "scheme": {"purelib": {"<project dir>": "<project dir>"}}}
}

{
   "version": 1,
   "scheme": {
      "purelib": {
        "<project dir>/.editable/_register_importer.pth": "<project dir>/_register_importer.pth".
        "<project dir>/.editable/_editable_importer.py": "<project dir>/_editable_importer.py"
      }
    }
  }
}

Rejected ideas

This PEP competes with PEP 660 and rejects that proposal because we think the mechanism of achieving an editable installation should be within the frontend rather than the build backend. Furthermore, this approach allows the ecosystem to use alternative means to accomplish the editable installation effect (e.g., insert path on sys.path or symlinks instead of just implying the loose wheel mode from the backend described by that PEP).

Prominently, PEP 660 does not allow using symlinks to expose code and data files without also extending the wheel file standard with symlink support. It’s not clear how the wheel format could be extended to support symlinks that refer not to files within the wheel itself, but files only available on the local disk. It’s important to note that the backend itself (or backend generated code) must not generate these symlinks (e.g., at interpreter startup time) as that would conflict with the frontends book keeping of what files need to be uninstalled.

Finally, PEP 660 adds support only for purelib and platlib files. It purposefully avoids supporting other types of information that the wheel format supports: include, data and scripts. With this path the frontend can support these on a best effort basis via the symlinks mechanism (though this feature is not universally available - on Windows require enablement). We believe its beneficial to add best effort support for these file types, rather than exclude the possibility of supporting them at all.

References

1

https://pypa-build.readthedocs.io

2

https://pypi.org/project/editables

3

https://flit.readthedocs.io/en/latest/index.html

4 (1, 2)

https://flit.readthedocs.io/en/latest/cmdline.html#cmdoption-flit-install-s

5 (1, 2, 3)

https://pip.pypa.io

6

https://setuptools.readthedocs.io/en/latest/userguide/commands.html#develop-deploy-the-project-source-in-development-mode

7 (1, 2, 3, 4)

https://setuptools.readthedocs.io/en/latest/

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.