Excuse me, but what I meant to say is that sys.path would be adjusted after the subprocess was loaded (in my implementation I adjust sys.path and os.environ['PYTHONPATH']).
2017-08-19 16:22 GMT-04:00 xoviat <xov...@gmail.com>: > 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
