On May 30, 2017, at 2:17 PM, Brett Cannon <firstname.lastname@example.org> wrote:Just to make sure I'm following this correctly, Donald is asking for:
- A way for pip to ask back-ends what files should be in an sdist from a source checkout or to make an actual sdist
- Because sdists are a thing and so we should support them properly
- To make it so building wheels interact with just the files from an sdist instead of skipping that and going straight from a source checkout
- Have this be a part of PEP 517 or at least a requirement for back-ends to support so it doesn't get left outAm I missing anything?More or less. If I had my druthers we’d just add another mandatory method to the API, something like:def build_sdist_tree(sdist_directory, config_settings) -> None:…All this does is assemble the would be sdist tree into sdist_directory, handling any sdist creation time steps WITHOUT actually tar+gz’ing up this tree. My tests show that this is basically as fast as the copytree option in the simple case (which makes sense, that’s basically all it is) and is way faster than actually assembling the entire sdist tarball and all.
To handle creation, we can either have ``twine sdist`` or something like that which just calls the above API and then runs ``shutil.make_archive()`` on the final directory.
When building a wheel, pip can then just inside of this directory, call into the wheel metadata/wheel build API and ultimately install that wheel. It may even make sense for the build_wheel API to produce an “unpacked wheel” as well and again let something like ``twine wheel`` handle running ``shutil.make_archive()`` on it. Similar to the sdist case, this would further reduce the install time by avoiding the need to zip and then immediately unzip inside of pip.
One unrelated thing I just noticed, I don’t think the PEP states how pip is supposed to communicate to this API what it’s actually building. Is it just assumed to be ``os.curdir()``? Ideally I think we’d add another parameter to all of these functions that is the directory containing the “input” to each of these.