On 2 June 2017 at 06:45, Brett Cannon firstname.lastname@example.org wrote:
And so I think in a very wordy way, I just said we need to stop saying "pip needs a standardized way to produce an sdist" and instead start saying "twine needs a way to produce an sdist". And that leads to the question about whether PEP 517 must cover sdist production for twine because we want to have that solved before we have the consumption side in pip in place. Or put another way, are we okay with pip consuming things that twine simply can't make from a pyproject.toml file (yet)? A "yes" means PEP 517 shouldn't be held up, while a "no" means we need a solution for twine.
I largely agree with this phrasing of the problem, but think it's oversimplifying the underlying capabilities needed a bit:
The agreed-to-be-missing piece that has been identified in PEP 517 is "2a": the part that will let pip (and any other tools doing out-of-tree builds) avoid copying entire VCS checkouts into the build directory.
Donald's perspective is that instead of being an independent step, generating an out-of-tree build directory should instead be defined in terms of sdist generation on the following grounds:
tox, which relies on sdist generation to push the code under development into the test venv
PKG-INFOin an sdist is essentially the same file as PEP 427's
METADATA, so any wheel building backend is already required to be able to generate it
While the first point doesn't really bother me (I'm OK with folks needing to keep a "setup.py sdist" shim around for now), I have to agree that I find the second point compelling, as it means that any PEP 517 based project will inherently test the correctness of its sdist generation just by doing a local install. That means we won't be relying on opt-in pre-release testing with tox, or post-release bug reports from users any more: if the sdist definition is broken, even local installations from the VCS checkout into an active virtual environment won't work.
The last point means that requiring an sdist export command shouldn't impose an unreasonable burden on backend developers, as the only differences between "generate an sdist tree" and "export a build tree" would be:
pyproject.tomlMUST be included unmodified at the root of the sdist tree
PKG-INFOMUST be generated at the root of the sdist tree
setup.pyshim MAY be generated for backwards compatibility with installation tools that are unaware of PEP 517
Beyond that, both approaches would have the same requirement of "include everything needed to subsequently build a wheel file from the sdist".
The mapping back to the originally identified activities would then be:
So even though 1a, 1b, and 2a are conceptually different activities, backends would only need to implement one operation to handle all 3: sdist export.
-- Nick Coghlan | email@example.com | Brisbane, Australia