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

[Donald Stufft]

> On May 31, 2017, at 3:12 PM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> 
> On Wed, May 31, 2017, at 07:40 PM, Donald Stufft wrote:
>> Taking pip completely off the table a second, let’s take a look at tox. Tox’s default mode of operation is to produce a sdist. Now let’s say I’m writing a project that I want to use PEP 517 and get rid of setup.py, except now tox is broken with no path forward because PEP 517 doesn’t define how to produce a sdist. 
>> 
>> The same story is true for TravisCI’s PyPI deployment pipeline, as soon as any project starts depending on PEP 517, we completely break that feature for them without a path for them to fix it (besides writing a PEP of course).
>> 
>> The same is true for Gem Fury’s private PyPI repositories where you can ``git push fury`` and have them build a sdist automatically for you.
> 
> These tools are all things that the developers of the project choose to use, however. I don't use them, so I'm happy enough to get rid of setup.py and not have a standard interface to building sdists. Developers who do use them will want to stick with setup.py until there's a standard way to build an sdist - or a tool like tox may add support for going via wheels instead of via sdist.
> 
> So PEP 517 may not be useful to *everyone* without standardising a way to build sdists, but it is still useful for many projects, and I don't think it prevents a later PEP from standardising a way to build sdists.


The most likely outcome if PEP 517 is implemented as defined and people who aren’t steeped in packaging lore hear about is, is they get excited about being able to kill setup.py, they implement it, they find out some tool they depend on doesn’t work and can’t work with it, they get discouraged and start filling issues. Ideally those issues are filed on the tool that implemented PEP 517, but most likely it will be filed on tox, Travis, GemFury, etc. 

I am struggling to figure out where there is opposition to simply exposing something in a standard way, that you were already planning on implementing anyways.

—
Donald Stufft



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