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
