On Thu, May 25, 2017, at 02:27 PM, Paul Moore wrote: > I'd be concerned here that we risk making the frontend UI a lot more > complex for little actual benefit. I'd rather we stick with the > current model, where a backend just has some output to pass through to > the frontend. Let's get a solution that works for that before adding > extra complexity, or we'll never get the PEP signed off.
I'm inclined to agree that we're overcomplicating things. But if we can't agree on which simple-but-imperfect option to take, maybe it's worth trying to work out something more complex. My proposed addition to the PEP so far says this: The build frontend may capture stdout and/or stderr from the backend. If the backend detects that an output stream is not a terminal/console (e.g. ``not sys.stdout.isatty()``), it SHOULD ensure that any output it writes to that stream is UTF-8 encoded. The build frontend MUST NOT fail if captured output is not valid UTF-8, but it MAY not preserve all the information in that case (e.g. it may decode using the *replace* error handler in Python). If the output stream is a terminal, the build backend is responsible for presenting its output accurately, as for any program running in a terminal. We could add a paragraph like this: The backend may do some operations, such as running subprocesses, which produce output in an unknown encoding. To handle such output, the build frontend MAY (?) create an empty directory, and set the environment variable PEP517_BUILD_LOGS to the path of this directory for the backend. If this environment variable is set, the backend MAY create any number of files inside this directory containing additional output. This is designed to allow the use of encoding detection tools on this output. If files are created in this directory, frontends SHOULD display its location in their output, and MAY display the contents of the files. That's not a massive amount more complexity for the spec, but it does add a moderate burden to frontend & backend implementations which want to properly support it. If you're being purist about it, displaying a path on a Unix based system is producing output in an unknown encoding, since filenames in Unix are bytes. I don't imagine many tools are going to go that far, though. Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
