[Distutils] PEP 517 - specifying build system in pyproject.toml

[Steve Dower]

On 22May2017 0803, Paul Moore wrote:
> On 22 May 2017 at 15:23, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> No, that's discussed here:
>> https://www.python.org/dev/peps/pep-0517/#comparison-to-competing-proposals
>>
>> Even though PEP 517 defines a Python API for build backends to
>> implement, it still expects installation tools to wrap a subprocess
>> call around the backend invocation.
>
> OK, but is it not acceptable for the child cmdline process (owned by
> pip) to capture the backend implementation's stdout using reassignment
> of sys.stdout? I assume, from your response, that it's *not*
> acceptable to do that - but that needs to be documented somewhere.
> Specifically, that the child cmdline is not allowed to do something
> like:
>
>     out = io.StringIO
>     sys.stdout = out
>     build_backend.hook()
>     print(out.getvalue(), encoding="UTF-8")
>
> (Which would otherwise be a very simple way to get guaranteed UTF-8 as
> the encoding across the process boundary - but it does so by imposing
> basically the rules I stated on the backend).

Okay, I think I get the problem now. We expect backends to let child 
subprocesses just spit out whatever *they* want onto the same stdout/stderr.

I'm really not a fan of forcing front ends to clean up that mess, and so 
I'd still suggest that the backend "tool" be a script to launch the 
actual tool and do the conversion to UTF-8.

Perhaps the middle ground is to specify encoding='utf-8', 
errors='anything but strict' for front-ends, and well-behaved backends 
should do the work to transcode when it is known to be necessary for the 
tools they run. (i.e. frontends do not crash, backends have a simple 
rule for avoiding loss of data).

Cheers,
Steve