Systematic cleanup and colorization of stack output

[mgsloan]

This issue is tracking doing a systematic sweep of the stack code and converting it to use the pretty-printer where appropriate.

I added some pretty print machinery to stack. In particular, we now have the following TH functions:

• $prettyDebug is just like $logDebug, except it expects an AnsiDoc value.
• $prettyInfo is just like $logInfo, except it expects an AnsiDoc value.
• $prettyWarn is similar to $logWarn, but it prepends a newline and "Warning: " colored yellow.
• $prettyError is similar to $logError, but it prepends a newline and "Error: " colored red.

One thing to note is that I would prefer colorization to be consistent across all of the stack messages. So, for the most part, colors should not be directly used in the stack source. Instead, add type and context specific utilities to `Stack.PrettyPrint. For example, I have these ones for plan construction:

displayTargetPkgId :: PackageIdentifier -> AnsiDoc
displayTargetPkgId = cyan . display

displayCurrentPkgId :: PackageIdentifier -> AnsiDoc
displayCurrentPkgId = yellow . display

displayErrorPkgId :: PackageIdentifier -> AnsiDoc
displayErrorPkgId = errorRed . display

Related issues that this work would ideally cover:

• Unclear error message for invalid extra-package-dbs Unclear error message for invalid extra-package-dbs #1738"
• Add a proper system for stack warnings suppression / collection / display Add a proper system for stack warnings suppression / collection / display  #1745"
• Pretty print long commands Pretty print long commands #1836
• Better formatting and parameter documentation when initializing a project Better formatting and parameter documentation when initializing a project #1911
• Improve error messages for yaml parse errors Improve error messages for yaml parse errors #2374
• Improve error message for bad build targets Improve error message for bad build targets #2384
• Prepend warnings with "Warning:" outside verbose mode so they're not taken as errors Prepend warnings with "Warning:" outside verbose mode so they're not taken as errors #2470
• Improve error/warning reporting in stack sdist and stack upload Improve error/warning reporting in stack sdist and stack upload #2507

[mgsloan]

Assigning myself, but if someone is interested in learning this pretty print stuff and doing the work, feel free to take it over / pitch in!

Are you interested @luigy ? I know you were interested in improving some aspects of stack's CLI display.

[kadoban]

I think I'd be interested enough to take on at least some of this. Is there a branch or any context I should look at, or just start in s/S/PrettyPrint.hs and look for places it should be used and etc.?

[mgsloan]

@kadoban Awesome! I think the best place to start would be uses of logWarn, since there are still a fair number of cases where it's unclear that the message is a warning. Using prettyWarn prefixes with a yellow "Warning:". Handling logError would also be good, for similar reasons (and better layout!). Taking a look at the uses of logInfo would be good too, though probably a lot of those can be left unchanged.

May also be worth considering switching over to https://www.stackage.org/package/prettyprinter-ansi-terminal / https://www.stackage.org/package/prettyprinter . Though, from a cursory glance at the code, it isn't quite as efficient in its use of control codes (mine avoids doing a state reset for every color change). Thinking that might be a better choice for simplicity / more reliable if output gets interspersed.

I suppose it'd be better to switch to the prettyprinter package before adding a lot more use of prettyprinting, though the API should be quite similar since they are both in the wadler-leijen family.

[kadoban]

Cool, thanks for the info. I'll get looking in to things and start a WIP PR or a branch or something tonight. I'll probably try a place or two and then look at which prettyprinter to use once I have a basic idea of what I'm doing and how the interface seems like it's working and etc.

[kadoban]

What would be your preference for small, obvious changes to switch to pretty* functions? Should I do small PRs, one big PR, or just push to master?

Anything interesting I'll make a PR for, and the terminal detection of course, but I suspect it'll just be tedious doing PRs for every little change (or one big, never-ending PR could also be kind of bad for merge-conflict reasons). But I'm find doing whatever really.

[mgsloan]

I think my preference is medium sized PRs, but it's pretty much up to you, one big PR is alright as well. One way to do it might be to do a big PR, but push to it as you go.

Thanks for working on this, good stuff!

[kadoban]

I think my preference is medium sized PRs, but it's pretty much up to you, one big PR is alright as well. One way to do it might be to do a big PR, but push to it as you go.

Sure, that works. Maybe I'll do something like module-by-module for a while and see how that goes. I have a decent start at s/S/Package.hs I think, going to throw it in a WIP PR.

Thanks for working on this, good stuff!

Anytime, thanks for reviewing and advice!

[kadoban]

Won't have time until monday for more stack almost certainly. On monday, I'm planning on anything that comes up for #3384, and then terminal detection if nobody gets to it first. Pretty excited for terminal detection, that should be fun and satisfying. :) Edit: out of date scheduling stuff.

[mihaimaruseac]

Now that #4205 is done, we can close this too.