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

[Nick Coghlan]

On 2 June 2017 at 18:37, Paul Moore <p.f.moore at gmail.com> wrote:
> On 2 June 2017 at 08:49, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The last point means that requiring an sdist export command shouldn't
>> impose an unreasonable burden on backend developers, as the only
>> differences between "generate an sdist tree" and "export a build tree"
>> would be:
>>
>> - `pyproject.toml` MUST be included unmodified at the root of the sdist tree
>> - `PKG-INFO` MUST be generated at the root of the sdist tree
>> - a `setup.py` shim MAY be generated for backwards compatibility with
>> installation tools that are unaware of PEP 517
>
> Note that a full "build an sdist" process should include a means for
> authors to add extra files (such as README, LICENSE, ...). But that
> can be either something that backends deal with themselves or (better)
> gets standardised in a separate PEP (probably defining a new set of
> `pyproject.toml` fields for it). It's not inherently something we need
> right now in PEP 517.

I think we can leave this as a backend level thing, as it really is
entirely up to the backend. From a frontend's perspective,
"Recursively copy everything that doesn't start with '.' and then
generate PKG-INFO" would be an entirely acceptable sdist export
implementation, as would "Export all files that are under source
control and then generate PKG-INFO". More complex backends may want
more sophisticated options than that, but they can still go in a
backend dependent configuration file (ala MANIFEST.in for
distutils/setuptools) rather than needing to be standardised.

Cheers,
Nick.

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