[Distutils] A possible refactor/streamlining of PEP 517

[Nick Coghlan]

On 17 July 2017 at 18:29, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The minimal specification for in-place builds is "Whatever you would
>> do to build a wheel file from an unpacked sdist".
>
> Eh no, in-place has nothing to do with building a wheel. Several people have
> already pointed this out, you're mixing unrelated concepts and that's likely
> due to you using a definition for in-place/out-of-place that's nonstandard.

I'm using in-place specifically to mean any given PEP 517 backend's
equivalent of an unqualified "./setup.py build_wheel". For an
autotools backend, that might ultimately mean something like
"./configure && make python_wheel". It *doesn't* necessarily mean the
equivalent of "./configure && make", because it wouldn't make sense to
assume that a project's *default* build target for a full-fledged
build system will be to make Python wheel files (fortunately,
frontends won't need to take, since hiding those kinds of details will
be up to backends).

I'm using out-of-tree to mean (as a baseline) what Daniel suggested:
any given backend's equivalent of "./setup.py build -b
<build_directory> build_wheel" (e.g. variant directories in Scons).

One additional config setting needed: the build/target directory

This approach means that backends can implement build directory
support without caring in the slightest about how Python frontends
intend to use it, and without worrying overly much about the different
kinds of source directory (VCS clone, unpacked VCS release tarball,
unpacked sdist) except insofar as they'll need to be able to detect
which of those they've been asked to build from if it matters to their
build process (e.g. generating Cython files in the non-sdist cases).

The non-standard semantic convention being proposed specifically as
part of PEP 517 is then solely that for frontends like pip, if
build_sdist fails, they should fall back to just asking the backend
for an out-of-tree build, rather than doing anything more exotic (or
Python-specific). This *won't* give them the general assurance of
sdist consistency that actually building via the sdist will, but
that's fine - the assumption is that a frontend that cares about that
assurance will only be using this interface if the sdist build already
failed, so full assurance clearly isn't possible in the current
environment.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia