<div dir="ltr">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']).</div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-19 16:22 GMT-04:00 xoviat <span dir="ltr"><<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. </div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-08-19 16:10 GMT-04:00 Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">It's probably a tiny wrapper running the hook in its own subprocess. Probably few modules loaded.</p>
<br><div class="gmail_quote"><div><div class="m_9175701992102743651h5"><div dir="ltr">On Sat, Aug 19, 2017, 14:31 xoviat <<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_9175701992102743651h5"><div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-19 14:23 GMT-04:00 xoviat <span dir="ltr"><<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>What do others think?</div></div><div class="m_9175701992102743651m_-5520576217223617975m_-4939031851087292716HOEnZb"><div class="m_9175701992102743651m_-5520576217223617975m_-4939031851087292716h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-08-18 23:41 GMT-04:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 19 August 2017 at 05:28, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk" target="_blank">thomas@kluyver.me.uk</a>> wrote:<br>
> We've probably all wished that the discussion could be brought to a swift<br>
> conclusion. But there are real questions to work out, and people have many<br>
> other things to pay attention to. I'm frustrated by how long it's taking as<br>
> well, but there's no magic button anyone can press to make it go quickly.<br>
<br>
</span>Technically, commercial redistributors do have a magic button we could<br>
press called "ongoing funding for sustaining engineering in the<br>
upstream Python ecosystem" (since that kind of funding can also cover<br>
needs-driven UX improvements), but alas, whether or not we ever<br>
actually press that is conditional on potential customers pressing the<br>
"customer demand" button hard enough and often enough to light up the<br>
"viable business opportunity" sign :P<br>
<br>
I'm actually genuine curious to see how those commercial dynamics<br>
start changing as the end date for community support of the Python 2.x<br>
series gets closer :)<br>
<div class="m_9175701992102743651m_-5520576217223617975m_-4939031851087292716m_-2840409646523306396HOEnZb"><div class="m_9175701992102743651m_-5520576217223617975m_-4939031851087292716m_-2840409646523306396h5"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div><span>
______________________________<wbr>_________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/distutils-sig</a><br>
</span></blockquote></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>