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

[Paul Moore]

On 25 May 2017 at 13:26, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 24 May 2017 at 20:29, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
>> 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?
>
> I'm genuinely unsure. The main downside of the directory based
> approach is that it doesn't play well with CI systems in general -
> those are typically set up to capture the standard streams, and if you
> want to capture other artifacts, you either have to stream them
> anyway, or else you have to use a CI specific upload mechanism to keep
> them around.
>
> I guess what we could do is have a "debug log directory" as part of
> the defined interface between the frontends and the build backends,
> and then the exact UX of dealing with those build logs would then be
> something for frontends to define (e.g. offering an option to
> automatically stream the logs after a failed build, with appropriate
> headers and footers around each file)

To me, this feels like a lot of potentially unnecessary complexity. At
the moment pip's UI works around "run a build, get some output,
display the output if the situation warrants (i.e., there was an
error)". The only stumbling block is over transferring that output
from backend to frontend where we need to consider text/bytes issues.

We're now talking about potentially managing a directory containing
logs, do we need to persist log files, should we display the file
content or just the filename, etc.

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.

Paul