[Distutils] PEP 517: Build system API

[Chris Barker]

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.

Back in the day I struggle mightily with kludging sys.path, and, relative
imports that never really worked right, and on and on -- it SUCKED.

Then I discovered setuptools develop mode -- yeah! IN fact, I don't think
I'd ever use setuptools at all if I didn't need it to get develop mode!

c. Decide that editable installs are too fiddly to standardise, and
> leave it to users to invoke a tool directly to do an editable install.
>

Not sure what that means -- does that mean that you couldn't get an
editable isntall with pip? but rather you would do:

setup.py develop   if you had setuptools as your build system, and

some_other_command  if you had some other build tool?

Not too bad, but why not have a standard way to invoke develop mode? If the
tool can support it, why not have a way for pip to tell an arbitrary build
system to "please install this package in develop mode"

On the other hand:

I've always thought we were moving toward proper separation of concerns, in
which case, pip should be focused on resolving dependencies and finding and
installing packages.

Should it even be possible to build and install a package from source with
pip?

But if it is, then it might as well support editable installs as well.

The complication I see here is that a tool can't know how to install in
editable mode unless it knows about the python environment it it running in
-- which is easy for a tool built with python, but a problem for a tool
written some other way.

However, I see from PEP 517:


The build backend object is expected to have attributes which provide some
or all of the following hooks. The commonconfig_settings argument is
described after the individual hooks:

def get_build_requires(config_settings):
    ...


So I guess we can count on a Python front end, at least, so 1(a) should be
doable.

In fact, is the user-install issue any different for editable installs than
regular ones?

-CHB













> 2. Dash vs. underscore, bikeshed reloaded! Currently,  the table name
> uses a dash: [build-system], but the key added by PEP 517 uses an
> underscore: build_backend. This seems a bit messy. I propose that we
> change build_backend to build-backend for consistency. Dashes and
> underscores can both be used in a TOML key without needing quoting.
>
> Thanks,
> Thomas
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20161123/55bc348a/attachment.html>