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

[Nick Coghlan]

On 4 June 2017 at 10:39, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
> On Sat, Jun 3, 2017 at 8:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> On 3 June 2017 at 03:14, Nathaniel Smith <njs at pobox.com> wrote:
>> > So far my belief is that packages with expensive build processes are
>> > going to ignore you and implement, ship, document, and recommend the
>> > direct source-tree->wheel path for developer builds. You can force the
>> > make-a-wheel-from-a-directory-without-copying-and-then-install-it
>> > command have a name that doesn't start with "pip", but it's still
>> > going to exist and be used. Why wouldn't it? It's trivial to implement
>> > and it works, and I haven't heard any alternative proposals that have
>> > either of those properties. [1]
>>
>> I may be misunderstanding you, but it's deeply concerning if you're
>> saying "as a potential backend developer, I'm sitting here listening
>> to the discussion about PEP 517 and I've decided not to raise my
>> concerns but simply to let it be implemented and then ignore it".
>
>
> I think you partly misunderstood - "ignore you" should mean "ignore pip" or
> "ignore the mandatory sdist part of PEP 517" not "ignore all of PEP 517".
> And concerns have been raised (just rejected as less important than the
> possibility of more bug reports to pip)?
>
> And I agree with Nathaniel's view in the paragraph above.
>
>>
>> OTOH, I'm not sure how you plan on ignoring it - are you suggesting
>> that projects like numpy won't support "pip install numpy" except for
>> wheel installs[1]?
>
>
> Of course not, that will always be supported. It's just that where the
> developer/build docs now say "python setup.py ..." we want them to say "pip
> install . -v" and with sdist generation that won't happen - they will
> instead say "somenewtool install ."

Allowing software consumption frontends like pip to completely replace
setup.py as a *development* tool isn't one of the goals of PEP 517 -
while we want to enable the use of both simpler (e.g flit) and more
capable (e.g. Scons, meson, waf) alternatives without breaking end
user installation processes and other tooling, it's also entirely
acceptable for projects that are happy with setuptools/distutils as
their build toolchain to keep using it.

The subtitle of the packaging panel at PyCon US 2013 ended up being
"'./setup.py install' must die", *not* "./setup.py must die" or
"./setup.py sdist must die", and that focus specifically on software
consumption wasn't an accident.

Personally, I'm thoroughly opposed to commingling software publishing
tasks and software consumption tasks in the same toolchain the way
distutils/setuptools do (since you can't optimise for the needs of
both software publishers *and* software consumers at the same time
outside relatively narrow domains like the Chandler plugin system PJE
originally wrote setuptools to handle), so I think the mismatched
perspectives here may be due at least in part to my failing to
communicate that adequately.

When it appears otherwise, it's because I'm conceding that a "pip
publish" front-end to a software publishing tool like twine may be
beneficial for discoverability and learning purposes when folks are
making the leap from "open source consumer" to "open source
publisher", and because "retrieve & unpack sdist, apply downstream
patches as needed, build & publish wheel" is a fairly common step in
automated build pipelines that inherently blurs the line between
software consumption and software publication :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia