[Distutils] A possible refactor/streamlining of PEP 517

[Nathaniel Smith]

On Sat, Jul 15, 2017 at 8:50 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 16 July 2017 at 04:33, Donald Stufft <donald at stufft.io> wrote:
>> All of that is a long winded way of saying I don’t particularly care if the
>> VCS -> wheel -> install path is spelled out *always* doing in-place builds
>> or if we add a build directory to specify between out of place or in place.
>> Having a robust mechanism in place for doing that means we can adjust how
>> things *typically* work without going back to the PEP process and throwing
>> everything away.
>
> +1
>
> The thing I like about the latest draft of the API is that it lets
> frontends choose freely between three build strategies:
>
> 1. build_sdist failing is a fatal error for the overall build
> 2. ask build_wheel to do its best to emulate a "via sdist" build with
> what's available
> 3. ask build_wheel for a wheel without worrying too much about
> matching the sdist

I guess here you're identifying (2) with "out-of-place builds" and (3)
with "in-place builds"?

But... that is not what the in-place/out-of-place distinction means in
normal usage, it's not the distinction that any of those build systems
you were surveying implement, and it's not the distinction specified
in the current PEP text.

If what we want is a distinction between "please give me a correct
wheel" and "please give me a wheel but I don't care if it's broken",
then wouldn't it make more sense to have a simple flag saying *that*?

And in what case would a frontend ever set this
give_me_a_correct_wheel flag to False? I know this sounds like a
rhetorical question, but it's not; if a distinction between these is
meaningful then there should be some concrete guidance we can give for
frontends to choose between them, and for backends to decide which
flag setting should behave in which way.

Alternatively, would it help to add some language to the PEP saying
that build_wheel MUST always produce the same output as
sdist->unpack->build_wheel? (I.e., basically making the
give_me_a_correct_wheel=True flag the only option, and then if it
turns out that sloppy builds have some compelling use case we can add
that later.)

In particular, I think we could then say that since for
distutils/setuptools, MANIFEST.in affects the sdist, then this
language means that their build_wheel hook MUST also be sensitive to
MANIFEST.in, and therefore it would need to be implemented internally
as sdist->unpack->bdist_wheel. (Or if someone's ambitious we could
even optimize that internally by skipping the pack/unpack step, which
should make Donald happy :-).) And OTOH other backends that don't do
this odd MANIFEST.in thing wouldn't have to worry about this.

-n

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