[Distutils] Provisionally accepting PEP 517's declarative build system interface

[Donald Stufft]

> On May 31, 2017, at 12:33 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 31 May 2017 at 16:31, Donald Stufft <donald at stufft.io> 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.

> 
> Paul
> 
> 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.

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170531/9e76ce4f/attachment.html>