[Distutils] PEP 517: Build frontend responsibilities
xoviat at gmail.com
Sat Aug 19 16:22:06 EDT 2017
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
>>> 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>
>>>> > We've probably all wished that the discussion could be brought to a
>>>> > conclusion. But there are real questions to work out, and people have
>>>> > 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
>>>> 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 :)
>>>> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
>> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG