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

[Thomas Kluyver]

On Thu, Jun 1, 2017, at 10:49 PM, Paul Moore wrote:
> pip also needs a way to deal with "pip install <local directory>. In
> this case, pip (under its current model) copies that directory to a
> working area. In that area, it runs the build command to create a
> wheel, and proceeds from there. In principle, there's little change in
> a PEP 517 world. But again, see below.

I still question whether the copying step is necessary for the frontend.
Pip does it for setup.py builds (AIUI) because they might modify or
create files in the working directory, and it wants to keep the source
directory clean of that. Flit can create a wheel without
modifying/creating any files in the working directory.

So, should PEP 517 specify that the backend building a wheel has to do
it without modifying/creating any files in the working directory? If the
backend can't be sure it will do that, it should copy whatever it needs
to a temporary directory and build from there. Tools falling back to
setup.py would copy as part of the fallback build step.

This seems to me neater than insisting that the backend copy all its
files even if there's no need.

As I mentioned on the PR, though, I don't feel strongly about this
issue. It's simple enough to copy all the necessary files to another
directory if that's what the build API requires.

> In a PEP 517 world,
> backends may or may not provide a "build a sdist" command (flit
> doesn't, and for a long time I believe didn't propose to do so -

Flit does as of a few days ago. But it's intended for developers
releasing a package, and so it relies on the code being in a VCS
repository and the appropriate VCS CLI being available. I don't want
this to be required when pip builds a package from source to install.

After quite a lot of discussion, I concluded that I want downloading and
unpacking an sdist to get me something very close to a fresh VCS
checkout of the corresponding release tag. Historically, we've often put
the results of things like code-generation into sdists, but I think that
was primarily because there was no good way to publish built
distributions, and so we hacked sdists into serving a bdist-like
function. Now that wheels are widely supported, I'm inclined to
discourage doing things like that with sdists.

Thomas