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

[Chris Jerdonek]

A couple comments:

1) Would it make sense to provide a way for build tools to specify
what encoding they use (e.g. if not using the default), instead of
changing their encoding to conform to a standard? It seems like that
could be easier, although I know this doesn't address problems like
non-conforming tools.

2) In terms of debugging, in cases where there are encoding-related
errors, it would help if the overall system made it easy to pinpoint
which parts of the system are at fault (using good error handling,
diagnostic messages, etc).

--Chris

On Tue, May 23, 2017 at 10:04 AM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> On Tue, May 23, 2017, at 04:20 PM, Nick Coghlan wrote:
>> Up to this point, I've been in favour of both 1b and 2b, since they're
>
> Noted.
>
>> However, I also realised that there's a potential third way to handle
>> this problem: design a Python level API that allows front ends to use
>> more structured data formats (e.g. JSON) for communication between the
>> frontend and their backend shim.
>>
>> In particular, I'm thinking we could move the current
>> "config_settings" dict onto something like a "build context" object
>> that, *even in Python 2*, offers a Unicode "outstream" and
>> "errstream", which the backend is then expected to use rather than
>> writing to sys.stdout/err directly. That context could also provide a
>> Python 3 style "run()" API for subprocess invocation that implemented
>> the preferred stream handling behaviour for subprocess invocation
>> (including applying the "backslashreplace" error handler regardless of
>> version)
>
> I'm not really compelled by this so far:
>