[Distutils] PEP 517: Build system API

Nathaniel Smith njs at pobox.com
Wed Nov 23 19:32:50 EST 2016

On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver <thomas at kluyver.me.uk>
> wrote:
>> Questions:
>> 1. Editable installs. The PEP currenly specifies a hook to do an
>> editable install (like 'pip install -e' or 'setup.py develop') into a
>> given prefix. I don't think that specifying a prefix is sufficient to
>> cover '--user' installation, which uses a different install scheme,
>> especially on Windows and OSX framework builds. We can:
>> a. Add an extra parameter 'user' to the hook, to override the prefix and
>> do a user install.
>> b. Leave it as is, and do not support editable user installation (which
>> would make me sad, as I do editable user installs regularly)
> Please, please, let's figure SOMETHING our here - editable installs (or
> "develop" installs) are a critical tool. Frankly, I don't know how anyone
> can develop a package without them.

Would a 'pip watch' command that watched your source tree and
rebuilt/reinstalled it whenever you edited a file work for you? What
do you do for conda packages? Does conda have an editable install

The problem with editable installs is that they can't really be made
to work "properly", in the sense of having solid invariants and
fitting nicely into a rigorously defined metadata model -- they're
always going to have weird footguns around the metadata / .py files /
.so files getting out-of-sync with each other, and they make it harder
to improve pip's infrastructure around upgrading, because upgrading
requires pip to have a solid understanding of exactly what's
installed. So it's absolutely possible to have some useful hack, like
we do now, but useful hacks by their nature are hard to standardize:
standardization means "this is the final solution to this problem, it
won't need further tweaking", and editable installs really feel like
they might benefit from further tweaking. Or something.

Also note that just like we decided to split the basic pyproject.toml
proposal (now PEP 518) from the build system interface proposal (now
PEP 517), it might (probably) makes sense to split the editable
install part of the build system interface proposal from the rest,
just in the interests of making incremental progress.


Nathaniel J. Smith -- https://vorpus.org

More information about the Distutils-SIG mailing list