[Distutils] PEP 517: Build frontend responsibilities

[xoviat]

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 <xoviat at 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 <dholth at 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 <xoviat at 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 <xoviat at 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 <ncoghlan at gmail.com>:
>>>>
>>>>> On 19 August 2017 at 05:28, Thomas Kluyver <thomas at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170819/59d57b6d/attachment.html>