Support CLIs that output data without logs mixed in

[antazoey]

Overview

right now, Ape does not afford outputting stdout from clis,

for example, this wont work:

ape vyper flatten file.vy >> out.vy

because log output is included.

The challenge is that logging happens way before the cli stuff.

Specification

one idea is to not log this early. instead, we can capture the messages and output them at a future time, if the log level is set.

another idea is to log to a file instead and use click.echo for stdout output. maybe in ape console we can always show logs.

tbd

Dependencies

Include links to any open issues that must be resolved before this feature can be implemented.

[linear[bot]]

APE-1711 Support CLIs that output data without logs mixed in

[antazoey]

@mikeshultz

[mikeshultz]

Kind of wonder if there's a way to prevent python logger from flushing to console until a certain point. Then we could use the ape_cli_context or whatever to kick it off. Though that would have bad implications for using ape as a lib...

I haven't come up with any grand ideas on this yet.

[antazoey]

I think like 70% of the logging we do in Ape could either be sent to a file instead (lower level stuff) or switched to click.echo() / rich.print().

We don't have to do this right now, but after the challenge we faced in the flatten cmd, I feel like this was worth tracking.

[mikeshultz]

Yeah, we need to separate what is just general logging data (debug and info stuff that's informative but doesn't necessarily need user attention) and console data that's part of the UI. UI level information should probably be entirely contained within CLI modules, which can control what is displayed (or not) to a user. Probably a painful refactor but could be useful for stdout piping as well as reducing the noise of the UI in general.

We could also separate out warnings and above and send them to stderr and it wouldn't poison anything that outputs to stdout.

[antazoey]

@mikeshultz That sounds good to me. 0.9 may be a good target for this. "Painful refactor" coincidentally is my middle name.