[Distutils] Provisionally accepting PEP 517's declarative build system interface

[Nick Coghlan]

[Note: I've reverted the PEP to Draft status while this discussion is
ongoing: https://github.com/python/peps/blob/master/pep-0517.txt]

On 3 June 2017 at 00:56, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> On Fri, Jun 2, 2017, at 03:41 PM, Nick Coghlan wrote:
>> Instead, the flow that I think makes sense is "VCS -> sdist tree [->
>> sdist tree -> sdist tree -> ...] -> wheel", and the above model where
>> the export filtering is only used when PKG-INFO doesn't exist yet will
>> give us that.
>
> I still object to conflating 'filter the files needed to build a wheel'
> with 'build an sdist' - these are different tasks which I would
> implement differently

This concerns me somewhat, as if a backend implements the two
differently, then it means building from an sdist and building from a
VCS checkout may give different results (since they may contain
different files).

Could you provide a little more detail as to what you would do
differently in exporting the contents of an sdist that wouldn't apply
to export a build tree? (aside from skipping emitting PKG-INFO)

>. And flit cannot do (sdist tree -> sdist tree).

It wouldn't be required to - since a PKG-INFO would be present in that
case, the front end would just copy the directory without bothering
the backend about it.

> The options as I see them:
>
> 1. Make it the responsibility of the backend, not the frontend, to build
> cleanly (except for setup.py builds). Then there's no need for a hook to
> filter a build tree before building a wheel.

No, we're not going to do that - build isolation will be the
frontend's responsibility.

> 2. Define a hook to filter the files into a build tree, as a separate
> notion from building sdists.

While Donald seems more amenable to this now, I still don't understand
the difference you see between the two (aside from PKG-INFO
potentially being unneeded in the build tree case, depending on how
the backend handles creation of the METADATA file)

Cheers,
Nick.

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