[Distutils] PEP 517 - a plan of action
p.f.moore at gmail.com
Sun Aug 27 06:37:17 EDT 2017
I feel that the discussion on PEP 517 is nearing an end. The
outstanding questions are pretty detail-level, and there's little
progress being made on them because the situations involved are mostly
theoretical in the absence of actual implementations. So I propose the
following plan of action:
1. Accept PEP 517 (at least provisionally).
2. Thomas to complete and publish his library of helper functions for
PEP 517 consumers (optional - but I think he said he had such a thing
3. Build PEP 517 interfaces for flit and setuptools.
4. Implement PEP 517 support in pip.
5. Review what we learned from the above.
6. If needed, revise the PEP in view of actual implementation
experience, and finalise it.
Further frontends and backends can wait for the results of this
process if they are concerned about tracking a provisional PEP.
Hopefully, it shouldn't be too long a process (I'd like to see PEP 517
in the next release of pip, if possible).
1. On any remaining questions for the PEP, let's just go for the
simplest solution for now. Let the PEP authors decide what that is,
with Nick as BDFL arbitrating if there's disagreement.
2. In my view, the PEP 517 support in pip should fully embrace the
principle in the PEP that it's the backend's job to ensure that
sdist->wheel and build_wheel produce equivalent results (when both are
possible), and should therefore *only* use build_wheel, at least until
experience demonstrates that we have to protect users against badly
3. My suspicion is that the setuptools backend will pretty clearly
demonstrate whether it's hard or easy to conform to the requirements
in the PEP, which can inform pip's stance on a "pure build_wheel"
4. If pip goes for direct wheel builds, this does mean that the
build_sdist and get_requires_for_build_sdist hooks won't be exercised
in any actual code during this process. IMO, that's OK, as those hooks
cover important (if currently theoretical) cases for validating the
"publish my project" workflow, and tools that want to address those
cases (such as tox) are likely to need the sdist hooks later.
If this seems like a reasonable plan, I'd suggest that people add
links to issues or PRs for PEP 517 implementations in flit, setuptools
and pip to this thread - as I'm sure all the participants here will
want to review the concrete implementations.
Please understand - I'm not trying to steamroller the process here, or
force particular decisions. It's just that I know I'm burned out on
the discussions, to the extent that I'm skimming mails and largely
ignoring many of the hypothetical arguments, and I'm sure others are
too. So we need to move to a point where we can discuss actual,
in-development code rather than possibilities, and I believe the above
plan gets us to that point as fast as possible.
More information about the Distutils-SIG