Don't (by default) output so much information during restore

[Alxandr]

Currently, when I run Sake on my tiny project which only dependency is Mvc it generates more than 1000 lines of output. All this debug information is nice to have, but it should be a bit more quiet by default. I'd like for it to output only the Installing {package} along with all completion messages and obviously any errors. If I want all the information, I should be able to get it using a -v switch (or similar).

[glennc]

We've added options to reduce the output now. The default is now quieter.

I'll close this, but re-open it if it's still too noisy for you.

[natemcmaster]

@glennc Can we revisit this? For big projects (such as EF), dnu restore still leads to hundreds of lines (seems like thousands when it has to get all the dependencies too.)

By default, I don't think users care to see every HTTP request made. Instead, I think users care:

1. that restore is making progress, and
2. that it worked or didn't. And maybe a summary of what happened.

dnu restore today looks a lot like npm install did in early 2014. I think it's ok to follow their lead.

The default log level has been reduced, so npm is a lot quieter. Rather than print out every HTTP request, npm now simply shows a spinner while it does stuff (so you know it hasn’t completely frozen)
From npm Progress - blog

[dougbu]

@natemcmaster does dnu restore --quiet not work for you?

[natemcmaster]

@dougbu It works, but even if we made --quiet default, this is still not the right UX. Because of #2304, I can't tell when it has hung or is just going slow.

I still believe the better experience is to be less verbose by default. As evidence, I just ran dnu restore on EF. It produced about 8,550 lines in my terminal. see log here. Nobody needs this much information by default.

[glennc]

at the moment the pinging of request response is also giving you the side effect of showing that something is happening. So as @natemcmaster said If we remove all of that then we will just close this issue so that we can open another where people are complaining that restore appears unresponsive for large periods of time.

Adding needs design to discuss what we want to do, at first cut it seems like collecting all the messages of the same type for a given package Id would be a good start. So instead of 5 gets for a package, since you have 5 package sources, you would get one. But we can talk about it and see.

[natemcmaster]

Just an idea:

Video

[Alxandr]

I like it.

Alxandr

[henkmollema]

Nice! What happens when an error occurs?

[davidfowl]

I'm not a fan. I understand the logs are excessive but this only works when you're interactive. It won't work in VS or on the CI machine. I think seeing the timings for http requests are useful as well. Maybe we only show ones that are beyond a particular threshold?

[Alxandr]

You could have VS and CI (sake) run restore with a flag, and by default show output like the one in the image above.

[natemcmaster]

@davidfowl I'm not sure why most users would need to see individual HTTP timings by default. That seems like debug info.

@henkmollema When errors occur, we could print those out and keep those on the screen, rather than overwriting the line as this demo does for successful operations.