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

[Steve Dower]

On 20May2017 1011, Thomas Kluyver wrote:
> On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote:
>> In general, since most subprocesses (at least on Windows) do not have
>> customizable encodings, the tool that launches them needs to know what
>> the encoding is. Since we don't live in a Python 3.6 world quite yet,
>> that means the tool should read raw bytes from the compiler and encode
>> them to UTF-8.
>
> I half agree, but:
> - Build tools may not 100% know what encoding output will be produced,
> especially if the developer can supply a custom command for the build
> tool to run.

In this case, the whole thing breaks down anyway. UI can't be expected 
to reliably display text from an unknown encoding - at some point it has 
to be forced into a known quantity, and IMHO the code closest to the 
tool should do it.

> - It's possible for data on a pipe to be binary data with no meaning as
> text.

Sure, but it cannot be rendered unless you choose an encoding. All you 
can do is dump it to a file (and let a file editor choose an encoding).

> - As a lazy developer, I don't want to read stdout/stderr from a
> subprocess only to spit it back to my own stdout/stderr. I'd much rather
> just launch the subprocess and let it use the same stdout/stderr as my
> build tool.

One of the open issues against distutils is that it does this. We can 
allow it, but a well-defined tool should capture the output and pass it 
to the UI component rather than bypassing the UI component.

> So I think it's most practical to recommend that build tools produce
> UTF-8 (if not sys.stdout.isatty()), but let build tool developers decide
> how far they go to comply with that.

Require that build tools either send UTF-8 to the UI component, or write 
bytes to a file and call it a build output. I see no benefit in 
requiring both the build tool and the UI tool to guess what the text 
encoding is.

Cheers,
Steve