In the PEP 517 discussions I kept returning to three different artifacts: the development checkout, the redistributable source release, and the installable wheel. Treating the first two as identical pushed work onto downstream builders that a release author could perform once.
The examples were concrete: derive version information from Git, generate C or headers from Cython or cffi, then build with the selected backend. Some of those inputs were available in the checkout’s history rather than as tracked files. Some required source-generation tools that the recipient of a release might not otherwise need.
The relevant distinction was:
checkout → prepare redistributable sources → compile/package → wheelGenerated source could belong in the middle artifact even when it did not belong in version control. That did not make the sdist a wheel; it changed which tools and inputs were required to build from it.
In my reply about source preparation, I asked whether the discussion was rejecting that preparation work or merely declining a separate build-directory parameter for the sdist hook. Those were different decisions. The latter could be reasonable without prohibiting generated material in a source release.
PEP 517’s terminology distinguishes a checkout-like source tree from a release snapshot and from the wheel built for installation. It also separates the frontend invoking the build from the backend that knows how to produce those artifacts.
The PEP did not adopt my proposed backend chaining. The question remained: which work should be done by the release author, and which work must the downstream builder repeat? Answering that requires naming the artifact being produced, not calling everything before a wheel simply “the source.”