[Distutils] PEP 517: Build frontend responsibilities

[xoviat]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170819/bffc8791/attachment.html>