On 23 May 2017 at 03:38, Steve Dower <steve.do...@python.org> wrote: > 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.
One of the key premises of PEP 517 is that there will be relatively few front ends (pip, possibly easy_install, ???), but a relatively large number of backends (one per build system - at least distutils/setuptools, distutils2, flit, encons, likely eventually meson, waf, and yotta, and potentially even C/C++ build systems like autotools, CMake, etc). So it makes sense to put the implementation burden for important aspects of the UX on the part that PyPA has the most influence over (the front-end), rather than considering it reasonable for front-end developers to point fingers and say "That UX failure in the tool we provide isn't *our* fault, it's the fault of the build backend developers for not complying with the interoperability specification properly"). Once we make that core assumption about where the responsibility for the end user experience resides, then the absolutely *minimum* behavioural requirements that can be placed on build backends are: - respect the locale encoding - emit informational messages on stdout - emit error messages on stderr What we can then also do is to recommend that *front-ends* do the following when invoking their build backend CLI shims: 1. Implement the C locale -> UTF-8 based locale coercion defined in PEP 538 when launching the subprocess 2. Implement a similar coercion for Windows, where cp1252 being active in the parent process prompts a call to "'chcp cp65001'" inside the subprocess before the build backend itself actually starts running That leaves build backend authors with the freedom to assume that they *don't* need to worry about stream encoding issues, since giving them access to properly configured streams is the front end's responsibility. > 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). In PEP 517's architecture, the front-end developers are also responsible for the CLI that's running inside the backend subprocess. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
