> On Jul 17, 2017, at 6:01 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > And I can completely see the point of folks saying "But you're > conflating two different questions" when I declare the latter notion > redundant given out-of-tree build support, since that's exactly what > I'm doing:
FWIW I consider the idea of a try-extra-hard flag (either explicit in the API or implicit in what kind of build you’re selected) a bad idea. While I ultimately “lost” the fight to narrow down the “variants” of installs to VCS -> sdist -> wheel -> install, I think adding a new variant of VCS -> funky try-harder but not as hard as sdist -> wheel -> install is only going to make things more confusing for end users as there is yet another subtle variant in their installs. I also don’t think it really even makes sense. If a backend had everything it needed to create a sdist, then it could have just successfully created the sdist and be done with it and we wouldn’t have called this hook. Since, aiui, the idea is to call this when sdists fail, then we’re assuming that for some reason the backend couldn’t create the sdist. Why do we assume that the backend is going to be capable of ensuring consistency with a sdist when it couldn’t create the sdist to begin with? In addition, why do we want a YOLO option that differs from the “try hard” version? Unless trying hard is some sort of super slow process (which it shouldn’t be, unless you’re creating a sdist as part of it, but if you can create a sdist why did build_sdist fail?) then it seems like you should just try hard always. I don’t care about in-place vs out-of-place builds. Add them, don’t add them whatever we can make it work either way. It seems like possibly a useful feature although Nathanial seems to have reservations that we haven’t fully thought through the implications of adding out of place building which seems like a legitimate concern. However, I am against having a “try hard” vs “YOLO” flag, explicit or implicit. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
