On May 31, 2017, at 12:33 PM, Paul Moore email@example.com wrote:
On 31 May 2017 at 16:31, Donald Stufft firstname.lastname@example.org wrote:
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
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.
— Donald Stufft