Cleaner output for build progress

[mgsloan]

I'm not sure who asked for this, I can't find it elsewhere in the tracker. I think it was an "l" name, possibly @luigy or @lwm. Or perhaps @sjakobi ? I also recall that there's another build tool that does this, not sure what. Anyway, the idea is that when running in standard verbosity, instead of listing when things have been started and are completed, we only list when important things have completed.

Currently, the "sticky" line in the output looks like Progress: 4/10. With this scheme, instead it would look like Progress 4/10: configuring mutable-containers-0.3.3, building mono-traversable-instances-0.1.0.0. It might be nice to have this "sticky" output take up multiple console lines.

By having info about what is currently being worked on, a lot of the output that stays in the console is no longer necessary. For example, take the following build output:

classy-prelude-1.3.1: unregistering (missing dependencies: mono-traversable, mono-traversable-instances, mutable-containers)
classy-prelude-conduit-1.3.1: unregistering (missing dependencies: classy-prelude, conduit-combinators)
classy-prelude-yesod-1.3.1: unregistering (missing dependencies: classy-prelude, classy-prelude-conduit)
conduit-combinators-1.1.2: unregistering (missing dependencies: mono-traversable)
minlen-0.1.0.0: unregistering (missing dependencies: mono-traversable)
mono-traversable-1.0.5.0: unregistering (local file changes: bench/sorting.hs)
mono-traversable-instances-0.1.0.0: unregistering (missing dependencies: mono-traversable)
mutable-containers-0.3.3: unregistering (missing dependencies: mono-traversable)
mono-traversable-1.0.5.0: configure (lib)
mono-traversable-1.0.5.0: build (lib)
mono-traversable-1.0.5.0: copy/register
minlen-0.1.0.0: configure (lib)
minlen-0.1.0.0: build (lib)
mono-traversable-instances-0.1.0.0: configure (lib)
mutable-containers-0.3.3: configure (lib)
mono-traversable-instances-0.1.0.0: build (lib)
minlen-0.1.0.0: copy/register
mutable-containers-0.3.3: build (lib)
conduit-combinators-1.1.2: configure (lib)
mono-traversable-instances-0.1.0.0: copy/register
conduit-combinators-1.1.2: build (lib)
conduit-combinators-1.1.2: copy/register
mutable-containers-0.3.3: copy/register
classy-prelude-1.3.1: configure (lib)
classy-prelude-1.3.1: build (lib)
classy-prelude-1.3.1: copy/register
classy-prelude-conduit-1.3.1: configure (lib)
classy-prelude-conduit-1.3.1: build (lib)
classy-prelude-conduit-1.3.1: copy/register
classy-prelude-yesod-1.3.1: configure (lib)
classy-prelude-yesod-1.3.1: build (lib)
classy-prelude-yesod-1.3.1: copy/register
Completed 8 action(s).

I would like to see the following instead:

Unregistered following packages due to local file changes (bench/sorting.hs):
  * classy-prelude-1.3.1
  * classy-prelude-conduit-1.3.1,
  * classy-prelude-yesod-1.3.1
  * conduit-combinators-1.1.2
  * minlen-0.1.0.0
  * mono-traversable-1.0.5.0
  * mono-traversable-instances-0.1.0.0
  * mutable-containers-0.3.3
mono-traversable-1.0.5.0 lib built
minlen-0.1.0.0 lib built
mono-traversable-instances-0.1.0.0 lib built
mutable-containers-0.3.3 lib built
conduit-combinators-1.1.2 lib built
classy-prelude-1.3.1 lib built
classy-prelude-conduit-1.3.1 lib built
classy-prelude-yesod-1.3.1 lib built
Completed 8 action(s).

Another nice idea here is related to sending output to the console. In #3666 , I'm making it so that benchmarks always send their output to the console. This isn't currently possible for tests because they run concurrently. However, with concurrent-tests: false, tests are not run concurrently with other tests. However, they are run concurrently with build steps. It seems quite reasonable to me to defer announcement that a build step has completed. So, you'd still have the sticky output indicating what is being worked on, and you'd get console output for every test. After a test runs, it'd output "lib built" announcements for every library that finished while the test was running.

It may even be worth making concurrent-tests: false a default, but not sure if the behavior change is worth it.

Pinging @kadoban - this is related to the overall prettification of stack's output, are you interested in taking it on?

[mgsloan]

Another idea here is that when output for a build or test is captured in a log, the path to the log should be displayed. Would make the build log noisier, but could be quite nice. Currently I don't think most users know about the log files.

[decentral1se]

Oh yes, putting the existing output into the log and getting at something like you posted would be cool.

The question that must be asked - is anyone relying on the current output for parsing? Hopefully not.

[mgsloan]

Yeah, let's hope not! If they are, well, this will probably be easier for that case too.

[mgsloan]

One thing to note is that it still makes sense to have the verbose log announce the different configure / build / etc stages. So, using logDebug / prettyDebug.