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

[Thomas Kluyver]

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

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

[Nick Coghlan]

On 24 May 2017 at 03:04, Thomas Kluyver  wrote:
> I'll propose a variant of an idea I described already: the frontend
> could provide the backend with a fresh temp directory. If the backend
> needs to run other processes, it can redirect the output into a file in
> that temp directory. Then you have files with an unknown encoding,  but
> each file will hopefully have one encoding, and you can use a tool like
> chardet to guess what it is.

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig