On Wed, May 24, 2017, at 01:22 AM, Chris Jerdonek wrote: > 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.
Interesting idea, but I'm not convinced it actually makes anything easier. You still have the same issues if the backend runs a subprocess which doesn't produce output in the expected encoding. And there would be some small amount of added complexity to communicate the encoding to the frontend. > 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). Agreed. Nick: > That's actually pretty similar to the way tools like mock (the chroot > based RPM builder) work. That way, build backends could choose > between: > > - use pipes to stream output from the tools they call, deal with > encoding issues themselves > - redirect output to a suitable named file in the tool log directory Do you know if that system works well for mock? Shall I try to draft a spec of something like this for PEP 517? Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
