[Distutils] A possible refactor/streamlining of PEP 517

[Ralf Gommers]

On Mon, Jul 17, 2017 at 8:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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".


Thanks. Very much nonstandard and possibly circular, but at least you've
defined it:) I suggest you pick more precise wording, because this leaves
little room for the more common use of in-place. Which you can define in
several flavors as well, but all of them definitely have the property that
if you put the source directory on sys.path you can import and use the
package.  build_wheel does not have that property.

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).
>

Leave off build_wheel (which is some metadata generation + zipping up the
right files on top of building), then out-of-tree build is a clear concept.


>
> 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).
>

This seems useful and clear.


>
> 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,


Say "asking the backend to build a wheel in a clean tmpdir" or something
like that. Not clear who decides the path to the build dir by the way, is
it frontend or backend or or
frontend-if-it-specifies-one-otherwise-up-to-backend?


> rather than doing anything more exotic (or
> Python-specific).


Building a wheel is inherently 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.
>

That strategy makes sense, seems like there's consensus on it.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170717/f2b84c5b/attachment.html>