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

[Paul Moore]

On 29 May 2017 at 11:46, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> Talking about a "build a sdist" operation brings a whole load of
>> questions about whether there should be a sdist format, what about
>> sdist 2.0, etc into the mix. So maybe we should avoid all that, and
>> say that pip[1] needs a "copy a source tree" operation. Backends
>> SHOULD implement that by skipping any unneeded files in the source
>> tree,but can fall back to a simple copy if they wish. In fact, we
>> could make the operation optional and have *pip* fall back to copying
>> if necessary. It would then be a backend quality of implementation
>> issue if builds are slow because multi-megabyte git trees get copied
>> unnecessarily.
>
>
> Doesn't that just move the problem from pip to backends? It's still a choice
> between:
> (1) making no copy (good for in-place builds and also fine for pbr & co, but
> needs education or a "pip release" type command)
> (2) making a full copy like now including .git, .vagrant, etc. (super
> inefficient)
> (3) making an efficient copy (will likely still break pbr and
> setuptools-scm, *and* break in-place builds)

Yes, that's precisely what it does. The point being that a backend is
the only code that can know what files are needed for the build, and
which ones can safely not be copied.

>
>> (This operation might also help tools like setuptools-scm that need
>> git information to work - the backend could extract that information
>> on a "copy" operation and pit it somewhere static for the build).
>
>
> If the backend can do it, so can pip right?

No (see above). pip has to make the safe "copy everything" assumption,
and that has a significant cost.

Paul