Pip 19.1 and installing in editable mode with pyproject.toml

Packaging
14

My current intuition is that a pep517 editable install can end-up being little more than a pass-through to the backend. IOW, something like “Dear backend, please install metadata and do whatever you think best for the source code in this local directory to be executable in place”. The current .egg-link method of setup.py develop would still be allowed, although considered legacy with maybe a long term deprecation path. In that view there should not be any backwards compatibility issue, because --editable + setuptools would still be allowed to work exactly as it does today.

Exactly, it’s really not very complicated. The hook could be:

build_inplace(site_packages_directory, config_settings=None):
    ...

Existing backends basically already do what is necessary:

  • setuptools executes its complex hierarchy of build commands initiated by setup.py develop and then creates an .egg-link file
  • poetry has poetry install, which uses poetry’s resolver and optionally calls a build script, and creates an .egg-link file generates a setup.py and calls pip install -e $pkg under the hood :unamused:
  • flit has a very minimal build and has the --symlink and --pth-file options for linking to site-packages

The question for me is if we want to go with real isolation of the build environment from the install environment, shouldn’t we let the build front-end be the one that actually makes the links? We could probably deprecate .egg-link that way, and the the build frontend make a platform-appropriate decision about how to include the source in site packages. For that, the signature would be:

def build_inplace(config_settings: Optional[dict] = None) -> Iterable[str]:
    ...

Where the resulting collection of str would be a list of paths to link onto site-packages. What do you think @sbidoul ?

In the worst case a compatibility issue is discovered while standardizing editable installs, it will still be possible to add a new pip option ( --inplace ?) for the new behaviour and keep --editable , as a setuptools-only function.

Or I think that might be the appropriate time to apply a --no-use-pepXXX flag, or just remove build-backend = setuptools.build_meta from pyproject.toml to force the old behavior (as the incompatibility would inevitably be with setuptools, I think). You wouldn’t really need a new name for the option. Although I like pip build -i|--inplace at some point