On 22May2017 0803, Paul Moore wrote:
On 22 May 2017 at 15:23, Nick Coghlan <ncogh...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
