dotnet restore needs a less chatty default verbosity level

[blackdwarf]

Currently, the default verbosity level is set to output the entire operation log to STDOUT. For new users this can be daungting. We should switch to a less chatty verbosity level by default.

/cc @billwert @piotrpMSFT

[natemcmaster]

👍 for quieter default. For big projects like EntityFramework, the default output of dotnet-restore can be literally thousands of lines long. Here is an idea we proposed for dnu restore but never implemented: aspnet/dnx#251 (comment)

[blackdwarf]

@natemcmaster for RTM we could go a long way if we default to --verbosity minimal honestly. It seems to provide success/fail response back to the user.

[emgarten]

Minimal should have everything but the HTTP request messages. I am fine with this change since the output can be overwhelming, but to provide some background on why network calls are shown by default today, it is to let the user know which source feed is slowing down the restore. Without this it can look like look like restore is hanging when it's actually being caused by a misbehaving source that the user may not realize they have.

Maybe NuGet could provide a short summary or warning if a source is extremely slow to solve the original problem without writing out every request.

[blackdwarf]

@emgarten thanks for the clarification. NuGet showing such errors in general in any verbosity level that displays output would be a good addtion.

[billwert]

@emgarten Having a summary of speed per source available would be good. The current thing doesn't print timings anyway, so I'd just be left to "feeling" which of the sources was slower or faster. (Unless one was just timing out but I'd like to think that's rareish.

[blackdwarf]

@billwert you may time out on a feed that is not nuget.org/official feed. For instance, you added a myget feed to your global Nuget.config file.

[billwert]

@blackdwarf Sure. Is the general case of using myget unstable enough that I need a lot of diagnostic output every time I run the tool? Or is it typically true that once I have a myget feed figured out and am using it in a stable way it will just stop working a lot?

[blackdwarf]

@billwert my point was just an explanation that you could be in a situation where the restore is slow/failing because in some config file you have a misbehaving feed. Replace "myget" with "internal corporate feed on a 386SX" and similar applies. :)

[emgarten]

@blackdwarf exactly :)

[billwert]

@emgarten @blackdwarf yup, this makes sense. I just don't have clarity on if we think this is the vanilla case and thus deserves to be in the output always or not. I think it does not and should be hidden between a more detailed verbosity level.

[blackdwarf]

@billwert that's true, which is why I think we should be on Minimal. Ideally, when we ship 1.0.0 we will have everything on nuget.org.

[TheRealPiotrP]

@emgarten can this issue be moved to nuget/home? I'd love for CLI not to override NuGet defaults by default. default default default.

[davidfowl]

I'm going to say no to this (again). Not showing progress for something like http request is literally the worst possible thing you can do. Having actually turned down the verbosity by default in dnu and originally nuget, I can tell you it's a hella bad idea.

[blackdwarf]

@piotrpMSFT we could just pass in a lighter verbosity level by default in dotnet restore.

@davidfowl how so? Like this, I'm getting tons of messages out of which a hefty ton are not actionable or I don't know are actionable. Not to mention that if I have several feeds the messages can easily flwo for so long that it is impossible for me to even do something unless I put them in a file and grep them later on if there is an error or something.

[natemcmaster]

IMO the issue here is a usable UX, not verbosity itself. Does a user understand when there is an error? Is it clear how to resolve it? Do they know when nuget is making progress vs stalled?

Logging every fetch makes it clear nuget hasn't stalled, but it buries warnings and errors in a mountain of output. In big projects, dotnet-restore can spew thousands of lines. (25,766 lines on a clean restore of EntityFramework: see this log).

[blackdwarf]

@natemcmaster yes, precisely. I just want dotnet restore by default to be more digestable to people. Giving me 500+ kb of text and then a "restore failed" in the end doesn't really help me figure out where the errorw was.

[billwert]

+1. By default tools should report progress and errors, and that's it. If there is a problem, I can re-run it with higher verbosity settings. If there is a constant problem, I can just always use those settings.

CLi should definitely crank this down to something manageable/useful.

[natemcmaster]

Just one more reason: our build of Entity Framework on Travis fails because the log from restore is too big. Restore output accounts for 86% of this log: https://s3.amazonaws.com/archive.travis-ci.org/jobs/114863155/log.txt

The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).

[blackdwarf]

@natemcmaster this really happened?? :) OK, we should fix this.

[natemcmaster]

@blackdwarf yes. https://travis-ci.org/aspnet/EntityFramework/builds/114863154

[david-driscoll]

This would be great to have in, it seems like --quiet doesn't do much at all.

This is a huge pain with OmniSharp trying to view things that actually failed. By the time we get to line 10000 (where travis cuts the file off) we're still restoring... not very helpful at all.

[brianrob]

+1 to progress reporting and errors. I'm happy to re-run higher verbosity when debugging. Right now, there is way too much output, and I'm never clear on whether things are OK or terrible.

[mellinoe]

@blackdwarf Any update on this?

[blackdwarf]

@mellinoe I believe @billwert created a PR for this, dotnet/cli#3229, which shows as merged.

[blackdwarf]

Closing as this is fixed.