[Distutils] PEP 517: Build frontend responsibilities

[Daniel Holth]

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/731984bd/attachment.html>