mirrord
mirrord copied to clipboard
metalbear-co
Provide feedback while the agent is initializing
The CLI currently silently waits for the agent to be up and running, since it can take a while it would be nice to show some minimal progress.
Thanks for the suggestion! This should be easily done by adding prints in the relevant places.
@aviramha you can assign this one to me.
Since it's a user-facing tool, I thought of using spinoff without colors for this to log the agent stages. Do you think it's worth the extra effort over just plain messages? Those have to be implemented for dumb terminals anyway.
@aviramha you can assign this one to me.
Since it's a user-facing tool, I thought of using spinoff without colors for this to log the agent stages. Do you think it's worth the extra effort over just plain messages? Those have to be implemented for dumb terminals anyway.
Done!
If you think spinoff is cool then yeah go ahead. One thing to notice is I thing that the prints/spinner should be enabled only when using the cli, as when it runs in extension/other mode it might trigger weird behavior (for example if the IDE debugger expects a debugee to have certain output and we'll start printing to stdout)
I'd expect it to be enabled by an env var in the mirrord-layer part which the cli sets.
I thought of just logging to stderr, so anything that expects output via stdout is unaffected.
I thought of just logging to stderr, so anything that expects output via stdout is unaffected.
Hmm I'm worried it might be too much magic for some (abusing stderr). @eyalb181 wdyt?
Thinking about it a bit more - in our tests with layer we assert stderr is empty for example..
I typically emit all user-facing logs to stderr in my applications so things that might consume stdout are unaffected by them (cargo does the same for compilation progress messages).
It's entirely possible to disable logs for dumb terminals as well of course like you suggest.
For me, stdout makes more sense here. We'd like to keep it enabled in dumb terminals too though, so we could use it to show progress in our IDE extensions.
Don't hate me but I think we should have different implementations based on flags.
MIRRORD_ENABLE_PROGRESS=std -> will have implementation of just printing lines/using spinners
MIRRORD_ENABLE_PROGRESS=ext -> will print jsons/other API friendly output
and by default it'd be off..
By default MIRRORD_ENABLE_PROGRESS would be off? Not std?
default of layer, cli will have it on by default.
Alright, so to summarize I'm thinking of 4 modes:
- fancy mode progress with spinner and whatnot, potentially with colors (windows is my concern regarding colors)
- less fancy but still user-readable (dumb) mode if the terminal is dumb or not a tty
- JSON mode for IDE integrations
- quiet/off, no output
All of them go to stdout, this means that user-readable output and JSON cannot coexist. The default is fancy for the CLI, which automagically turns into dumb, quiet for the layer, but if the layer is initialized via the CLI, it should set the env var for it anyway.
I would not implement JSON output with my PR as it needs to be properly specified as other software will depend on it.
I'd add a CLI option for --quiet for users as well outside the environment variables.
Next I'm thinking of how to collect this information, I believe we could just use tracing spans to track progress, this way we don't need to wire the progress tracking all the way in the code, just add spans and a subscriber layer that is configured in one of the above modes.
