Skip to content

Colorize daemon output and add summary line #7441

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

Merged
merged 5 commits into from
Sep 2, 2019

Conversation

ilevkivskyi
Copy link
Member

Fixes #7438

This PR makes the daemon behave the same way as the normal run (i.e. use colorized output and write a summary line). I also fix a minor bug that the summary line was colorized even if --no-color-output was passed.

The idea is quite simple, client passes to the server info about whether we are in tty and if yes server returns nicely formatted output. I tried running various commands on Linux and piping it through grep.

@ilevkivskyi ilevkivskyi requested a review from JukkaL September 2, 2019 11:20
Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, it's important that deamon and batch mode produce the same output. Only left some style nits.

@@ -265,12 +265,14 @@ def do_run(args: argparse.Namespace) -> None:
# Bad or missing status file or dead process; good to start.
start_server(args, allow_sources=True)
t0 = time.time()
response = request(args.status_file, 'run', version=__version__, args=args.flags)
response = request(args.status_file, 'run', version=__version__, args=args.flags,
no_tty=not sys.stdout.isatty())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way no_tty argument is used seems error-prone, since the caller accepts **kwargs: object. Why not calculate it in request unless explicitly provided. Maybe just send it always to server, for consistency? The server can then decide if it wants to deal with it. This would reduce some coupling, as if some command starts producing colored output, only the server would have to be updated. Anyway, at least it would be good to explicitly declare the argument in request if you don't get rid of it.

Also style nit: I'd avoid an argument with a negated boolean value. This could be renamed to is_tty, for example, and it would arguably be cleaner.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not calculate it in request unless explicitly provided. Maybe just send it always to server, for consistency?

Yes, I was actually also not happy that no_tty in **args would not be statically checked. I will try to tighten this.

Also style nit: I'd avoid an argument with a negated boolean value. This could be renamed to is_tty, for example, and it would arguably be cleaner.

OK, makes sense (also for the no_color below).

# If the daemon signals that a restart is necessary, do it
if 'restart' in response:
print('Restarting: {}'.format(response['restart']))
restart_server(args, allow_sources=True)
response = request(args.status_file, 'run', version=__version__, args=args.flags)
response = request(args.status_file, 'run', version=__version__, args=args.flags,
no_tty=not sys.stdout.isatty())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The above suggestion would get rid of the repeated not sys.stdout.isatty() calls.

mypy/util.py Outdated
return self.style('Success: no issues found in {}'
' source file{}'.format(n_sources, 's' if n_sources != 1 else ''),
'green', bold=True)
def format_success(self, n_sources: int, no_color: bool = False) -> str:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above, I'd prefer to avoid no_xxx boolean variable names.

not self.options.color_output or no_tty)
else:
summary = self.formatter.format_success(n_sources,
not self.options.color_output or no_tty)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The not self.options.color_output or no_tty expression is repeated here. It would be less error-prone to calculate it only once.

if summary:
# Create new list to avoid appending multiple summaries on successive runs.
messages = messages + [summary]
if self.options.color_output and not no_tty:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the third repeat of this expression.

@ilevkivskyi
Copy link
Member Author

@msullivan I also added support for MYPY_FORCE_COLOR in the daemon. But we should be careful with it in our wrapper scripts, we need to set it to '0' if a user pipes the wrapper script to grep etc.

@ilevkivskyi
Copy link
Member Author

Since the review comments were all minor here, I am going to merge this when tests pass (unless there are new comments or objections) and then rebase and update #7440 on top of this.

@ilevkivskyi ilevkivskyi merged commit 7b83c35 into python:master Sep 2, 2019
@ilevkivskyi ilevkivskyi deleted the color-daemon branch September 2, 2019 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support colorized output for daemon
2 participants