The previous wording could be taken as suggesting that frontends should opt
out of their PEP 517 processing entirely if build-backend was not defined,
whereas it's actually fine to just use the setuptools provided backend that
implements the legacy build semantics.
Later on in the same file, it says that the .zip example can't possibly work: "[source distributions] will be gzipped tar archives, with the .tar.gz extension. Zip archives, or other compression formats for tarballs, are not allowed at present."
This, and other documentation issues not fixed here, was noted in a blog post I was reading: https://blog.schuetze.link/2018/07/21/a-dive-into-packaging-native-python-extensions.html -- full credit to @konstin.
This adds an explicit "Provisional" status for PEPs, making
it easier to track which PEPs are truly Final, and which
are pending further further public feedback based on
their initially published reference implementations.
- replace with prepare_metadata_for_build_wheel where appropriate
- update the API evolution example to be based on build_sdist
rather than prepare_wheel_metadata
- also clarified the frontend example code covering one way to
handle prepare_metadata_for_build_wheel being optional
- update hook names and signatures
- clearly separate sdist building & wheel building
- add support for out-of-tree wheel builds
- clarify build_wheel spec based on updated example
- be explicit that out-of-tree builds should match
the results of building via sdist
- Add get_build_sdist_requires
- Rename hooks that had become ambiguous given
two distinct build hooks
- Clarify expected environments for the various hooks
An ambiguity in the wording made it look like metadata_directory for build_wheel
would be the same directory as was passed in to the prepare_wheel_metadata hook.
It makes more sense for it to be the .dist-info directory returned from prepare_wheel_metadata.
- use sdist and wheel archives as required interchange formats
- use `prepare_*` prefix for optional file export APIs
- return relative paths for generated aritifacts/directories
The provisional acceptance led to some additional valid concerns being raised
with the current design in the PEP, so I'm reverting it to Draft status
while we resolve them.
The key is in the build-system table, so making this a dash would
improve consistency. On English keyboards, it also avoids needing to
press shift. There seemed to be a consensus on distutils-sig in favour
of this change.
* 517: Remove install_editable hook (Option 1c)
This is the other option for --user editable installs: don't try to
standardise a mechanism. This could always be added back in a later PEP.
Alternative to gh-140
* Add note about removal of editable install