On 31 May 2017 at 16:31, Donald Stufft <email@example.com
The hook is also so a tool like tox or TravisCI or twine can produce a sdist that can be uploaded to PyPI or similar.
Understood. The part that the backend can do (these are the files
needed for the build process) is done via the hook. The rest (add
files requested by the user, generate metadata, ...) is backend
independent (or covered by a separate hook/not specified yet in the
case of metadata) and so should be done by the frontend tool.
I don’t think it’s backend independent though. You’re going to have different mechanisms for handling these things in different backends, for example one piece of the metadata is the version. Some projects will be fine with a static version, some projects are going to want to automatically deduce it using a VCS. Trying to cram all of these into a single tool falls into the same problem that PEP 517 is trying to solve.
PS When did Travis become a frontend? I'd have assumed that to produce
a sdist, Travis would *invoke* a frontend tool, such as "twine sdist".
Or am I unaware of some capability of Travis (highly likely)?
No you’re correct, it currently just invokes ``setup.py sdist bdist_wheel``. The hook is needed so that Travis can have a singular tool to invoke (likely twine?) instead of needing to determine if it needs to invoke flit or setuptools or mytotallyradbuildthing. The thing I’m trying to express (and doing poorly it seems :( ) is that generating a sdist is an important thing to have be possible, and it needs to be done in a way that it can be invoked generically.