Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support CLIs that output data without logs mixed in #1967

Open
antazoey opened this issue Mar 20, 2024 · 6 comments
Open

Support CLIs that output data without logs mixed in #1967

antazoey opened this issue Mar 20, 2024 · 6 comments
Labels
0.9 category: feature New feature or request

Comments

@antazoey
Copy link
Member

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.

@antazoey antazoey added the category: feature New feature or request label Mar 20, 2024
Copy link

linear bot commented Mar 20, 2024

@antazoey
Copy link
Member Author

@mikeshultz

@mikeshultz
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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

@antazoey antazoey added the 0.9 label Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.9 category: feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants