The possibility of doing it in setuptools is discussed extensively in the threads, but a lot of us are going off of half-remembered discussions, so it's probably a good idea to get a central "agenda" of the things we want to resolve and create a new thread for discussion in the discourse.
Items I see for the agenda: - The most urgent question for discussion that I see is what should be done /now/. This seems to me like a major issue, and I'm wondering if it would make sense to revert the major change in behavior until we iron out some of the details. It seems like many people in the thread (and people I've spoken to in person) are "solving" this by just pinning pip to < 19.0. - From the setuptools side, I think we don't want to be forced to rush things. setuptools is already a huge bundle of compromises and less-than-ideal defaults because we have so few opportunities to fix the crustier parts of it without introducing enormous code churn. I don't want us to have to put compatibility shims into our main build backend just to unbreak some people today if we can avoid it with a less permanent "band-aid" solution. On 1/27/19 9:39 AM, Thomas Kluyver wrote: > I haven't read those discussions in full (sorry to be lazy, but > there's quite a lot there), but my initial take is that the rule > doesn't apply to running setup.py scripts, where there's a greater > need for backward compatibility. I think the rule about the CWD not > being on sys.path only applies to loading a proper PEP 517 build > backend when that's specified in pyproject.toml. > > Furthermore, if the build backend then wants to run some code with the > CWD on sys.path, I think it's free to do so, so this could be > implemented in the setuptools backend. The rule is only for how the > frontend loads the backend, not what the backend does afterwards. > > Where a real PEP 517 backend needs to be loaded from the CWD (e.g. for > Flit to bootstrap itself), we've already got the intreehooks package > to make this possible: https://pypi.org/project/intreehooks/ > > > > On Sun, Jan 27, 2019, at 2:26 PM, Chris Jerdonek wrote: >> For those of you who participated in the PEP 517 discussion during >> the summer of 2017 (just prior to its provisional acceptance), I want >> to flag that one of the issues discussed back then has now resurfaced >> for discussion. This is because the feature was turned on by default >> in pip's latest release (19.0) less than a week ago. >> >> The issue is the one around whether the source directory should be >> included in sys.path. The resurfacing is more or less as predicted. >> For example, in one email [1] from August 29, 2017, Nick summarized >> the state of things by saying (not too long before provisional >> acceptance)-- >> >> So I think we can deem this one resolved in favour of "Frontends >> must ensure the current directory is *NOT* on sys.path before >> importing the designated backend", as starting there will mean we >> maximise our chances of learning something new as part of the >> initial rollout of the provisionally accepted API. >> >> >> And also-- >> >> 2. If omitting it is genuinely a problem, we'll likely find out >> soon enough as part of implementing a setup.py backend >> >> >> Basically, that "soon enough" moment has arrived, and at least one >> discussion on how to resolve it has started on the tracker here: >> https://github.com/pypa/pip/issues/6163 >> >> There is another discussion here, but it's probably better for the >> discussion to be in one spot: >> https://github.com/pypa/setuptools/issues/1642 >> Maybe Discourse? >> >> --Chris >> >> [1]: >> https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html >> >> -- >> Distutils-SIG mailing list -- distutils-sig@python.org >> <mailto:distutils-sig@python.org> >> To unsubscribe send an email to distutils-sig-le...@python.org >> <mailto:distutils-sig-le...@python.org> >> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ >> Message archived at >> https://mail.python.org/archives/list/distutils-sig@python.org/message/LMGQS2DCMDFMMIYXH3A7ZDZN55P3CFMV/ > > > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/archives/list/distutils-sig@python.org/message/G3FNWBTRUV5E4Z4MWDNOQ2PZTXLLD3XF/
signature.asc
Description: OpenPGP digital signature
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/ZGY5HEHQFGJ2FUVACKPUTU3ZZLQFB3RW/
