Specification of editable installation

Packaging
21

To give an update on the status of this after the Packaging mini-summit and the sprints, we have a fairly simple proposal that @pradyunsg and I are planning to turn into a proof of concept implementation, then a draft PEP.

We will add two functions to the backend interface:

  1. prepare_metadata_for_build_editable(source_directory, metadata_directory, config_settings=None): This is a required function that populates the release metadata (dist-info) files in the provided directory. It will likely always be the same as prepare_metadata_for_build_wheel.

  2. build_editable(source_directory, metadata_directory, config_settings=None): This function will build a “virtual wheel” by preparing all files to be installed and returning a dictionary where keys are locations of files and directories relative to the package root and values are the absolute locations of those files on disk. This does not include the dist-info metadata, which is returned separately in the prepare_metadata_* step.

An example of the “virtual wheel” format, for a package “foo” containing a single __init__.py, build_editable would return something like:

{
    "foo/": "/tmp/demo/src/foo/",
    "foo/__init__.py": "/tmp/demo/src/foo/__init__.py"
}

It would be the front end’s responsibility to make sure that at least the foo module is available to the system. Whether it accomplishes this with .pth files or symlinks or some other mechanism is up to the front-end and not part of the spec.

1 Like