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

[Paul Moore]

On 31 May 2017 at 20:20, Donald Stufft <donald at stufft.io> wrote:
> 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.

There's a lot of baggage associated with the term sdist.

As a suggestion - if backends supplied a prepare_build_files hook,
someone could write a pretty trivial tool that called that hook. Then
call the build_wheel_metadata hook to get some details to put into
PKG-INFO, zip the result up and call it a sdist. You could dump a
setup.py replacement in there that used PEP 517 hooks to implement the
setup.py interface, if you wanted.

Given how vaguely defined a sdist is, it would be hard to argue that
the result is *not* a sdist. I'm not sure how much further you're
going to insist on going. You no longer create a sdist using "setup.py
sdist", sure. But at some point the tools have to deal with setup.py
going away, so I don't see how that's a requirement forever.

If you really think we need to cover these use cases solidly (and you
have a point, I'm not saying they are irrelevant at all) then maybe we
need to get input from the tox/travis/gemfury devs, to see what they
actually think, rather than trying to guess their requirements?

Paul

PS None of this means I am in any way in favour of making it seem like
we're OK with projects not providing sdists (in some form or other).
We're an open source community, and I think publishing sources
alongside your binaries, is key to that. A link to an external source
code repository isn't sufficient, IMO (the repo could die, like Google
code did).