On May 30, 2017, at 2:17 PM, Brett Cannon brett@python.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 out Am 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.
— Donald Stufft