Yes, it probably is. But then again, I assumed that it was obvious that PYTHONPATH would not be modified before invoking the hook (at least obvious to me) until the 'PEP 517 Status' discussion implied that it was not so obvious and needed to be specified in the PEP.
2017-08-19 16:10 GMT-04:00 Daniel Holth <dho...@gmail.com>: > It's probably a tiny wrapper running the hook in its own subprocess. > Probably few modules loaded. > > On Sat, Aug 19, 2017, 14:31 xoviat <xov...@gmail.com> wrote: > >> Ah the joy of Python 2.7; it seems I've forgotten its perils: unloading >> is not possible which means that we would need to come up with another >> solution to this problem. Perhaps setting aside a namespace for the build >> frontend in the subprocess? >> >> 2017-08-19 14:23 GMT-04:00 xoviat <xov...@gmail.com>: >> >>> I assume that the outstanding issues mentioned are related to sys.path >>> in the build tree. My view on that is the following: the build frontend >>> should be responsible using any mechanism that it chooses for invoking the >>> build backend, which must be imported with '' at the front of sys.path. >>> This obviously means that if the build frontend experiences faults before >>> it manages to import and invoke the backend, then it's the build frontend's >>> fault. >>> >>> The only potential issue remaining that I can think of then is: what >>> about modules that are already imported when the build backend is called? >>> WRT standard library modules, we could simply say that build backends must >>> be prepared to function in any environment where standard library modules >>> are already imported, which I think is a reasonable requirement. But what >>> about imports that aren't standard library modules but are fairly common, >>> like pip imports? The simplest way to simplify the interface is probably to >>> say that all non-standard library modules must be removed from sys.modules >>> (unloaded) before the build backend is called. >>> >>> What do others think? >>> >>> 2017-08-18 23:41 GMT-04:00 Nick Coghlan <ncogh...@gmail.com>: >>> >>>> On 19 August 2017 at 05:28, Thomas Kluyver <tho...@kluyver.me.uk> >>>> wrote: >>>> > We've probably all wished that the discussion could be brought to a >>>> swift >>>> > conclusion. But there are real questions to work out, and people have >>>> many >>>> > other things to pay attention to. I'm frustrated by how long it's >>>> taking as >>>> > well, but there's no magic button anyone can press to make it go >>>> quickly. >>>> >>>> Technically, commercial redistributors do have a magic button we could >>>> press called "ongoing funding for sustaining engineering in the >>>> upstream Python ecosystem" (since that kind of funding can also cover >>>> needs-driven UX improvements), but alas, whether or not we ever >>>> actually press that is conditional on potential customers pressing the >>>> "customer demand" button hard enough and often enough to light up the >>>> "viable business opportunity" sign :P >>>> >>>> I'm actually genuine curious to see how those commercial dynamics >>>> start changing as the end date for community support of the Python 2.x >>>> series gets closer :) >>>> >>>> Cheers, >>>> Nick. >>>> >>>> -- >>>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >>>> >>> >>> >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG@python.org >> https://mail.python.org/mailman/listinfo/distutils-sig >> >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig