On 8 July 2018 at 04:42, Nathaniel Smith <n...@pobox.com> wrote: (I'm going to read your full mail in more detail before commenting, but I wanted to pick out this point immediately, as I think it's worthwhile addressing it in particular)
> If there's some reason we *don't* plan to eventually make > build-isolation mode the default, and will need to keep legacy code > paths inside pip indefinitely, then that makes this much more > complicated and I'd want to think it through more carefully. Hopefully > no-one sees any terrible flaws with making build-isolation the default > (eventually)? In principle, I'm 100% on board with this. However, as is typical with packaging changes, we have a huge backward compatibility situation to address - the many packages on PyPI that are infrequently updated or maintained and yet still in common use. We also have a large body of users who build pip into their internal workflows, who often rely heavily on what to "normal pip usage" are obscure edge cases. I'd like to find some way of assessing the impact before we simply switch to full build isolation (we've already had a fair number of bug reports on pip that are triggered by build isolation, such as the ones that started this discussion). The key question is how many users would be affected, and how much effort would it be for them to change. I'm going to make a point now that I've made before - this *only* affects people building from source, and in theory we're aiming for a world where "most" users do "pip install XXX" and download and install a set of pre-built wheels. In that world, PEP 518 behaviour is a relatively uncommon case, which is mostly needed by people who have the technical skills to deal with the change. But the pip issue tracker (which is hugely biased, as no-one raises an issue to say "I used pip and it worked - thanks!", sadly ;-)) seems to indicate that there's a lot more people building from source than we'd like to believe. So to summarise: Yes, build isolation as the default is what we want (IMO), but it's not at all clear to me how fast we can remove the legacy code paths, or how we can best smooth over the transition for our existing users. So for the moment, I'm assuming that some form of legacy (non-isolated) code path may be around for quite a while yet. Paul PS On a purely personal note, I'd prefer that we go full build isolation and drop the legacy code paths ASAP. But I'm very firmly in the "installs everything from wheels" user base, so it's not me that would suffer if we got this wrong... -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/26ZYVZZAYIHH22ZEXSIXHLTWMST6PQXC/
