On 24 May 2017 at 20:29, Thomas Kluyver <tho...@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) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
