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.