On 15 July 2017 at 19:42, Nathaniel Smith <njs@pobox.com> wrote:
Does that make sense? Does it... help explain any of the ways we're talking past each other?
I don't think you're talking past each other, I think you're explaining why Paul's preferred build strategy is for pip to always try creating and unpacking an sdist first, and only fall back to requesting an out-of-tree build from the backend if building the sdist fails (for example, due to VCS metadata or command line tools being missing). (Which does make it clear that my hope that pip might be able to avoid that outcome for the PEP 517 case isn't going to be realised). Requesting an out-of-tree wheel build is then just a way for a frontend to say to the backend "Hey, please build the wheel *as if* you'd exported an sdist and then built that, even if you can't actually export an sdist right now". I think the disconnect may be happening because you seem to think we're looking for an unattainable ideal and are going to be disappointed when we don't achieve it: a build system that is guaranteed to never fail. That's simply not possible, and hence not what we're aiming for. Instead, we have the significantly more modest goal of defining a build system where if a build works for a publisher, it will *probably* also work for their end users, *even if* the publisher only tests the "pip install ." case prior to pushing their sdist and wheel archives to PyPI, and even if the end user has unrelated junk in their source directory when doing the build. It's OK if there are still ways for people (both publishers and end users) to break their builds, as long as those breakages aren't arising from the *default* workflows, and are instead due to the specifics of how a project is using their chosen backend build system. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia