On 14 July 2017 at 21:23, Donald Stufft <donald@stufft.io> wrote:
* I think it is a requirement that any PEP that proposes a mechanism for removing ``setup.py`` supports sdist and wheel building in it’s interface. Otherwise it sends a message that either one is an optional part of Python packaging, which is not a message we should be sending.
I agree - although I accept that under certain conditions, certain backends might fail to produce a sdist (for example flit can't produce a sdist if the user doesn't have VCS tools installed). I'd rather they didn't, but that's a quality of implementation issue with the backend, and not something I think we should mandate.
* I would *like* to remove a fairly common error case where we have a difference in the files that get included in a sdist and the files that get installed such that ``pip install .`` causes different files to be installed than ``python setup.py sdist && pip install dist/*.tar.gz``.
I agree - for me, this is an important improvement that we can make to pip, and if the PEP makes it impossible for us to do this I'd be very reluctant to accept it. We could fall back to building via sdist, but if sdist creation can fail, that's a problem - so I'd have to rethink my willingness to accept that build_sdist could fail if we didn't get support for this.
* I would *like* to remove another common error case where two subsequent builds end up affecting each other (at least by default) because of detritus left behind from the first build process. One example I can think of is if you have a library that can optionally link against some other library, you might ``pip install .``, notice it didn’t link against that (because you didn’t have it installed) and then install it and ``pip install .`` again. Nothing would have changed in the directory to trigger a rebuild, so you’d get the behavior where it wouldn’t rebuild.
I have no real opinion on this one. Or at least, I'm not willing to get into fights about incremental build support at this time, so I'll abstain here. Paul