Add standard functions for command output.

Add standard functions for command output.

Add simple function support and flags around changing how the command output
works by default.  Add flag options for '-q' and '--quiet', and provider a
short '-d' for '--debug'. Also updated the text for the flags.

There are now two methods in the cmd package that should be used for output:
  cmd.Infof(...)
and
  cmd.Verbosef(...)

If quiet is specified, both are logged instead of written out. If verbose is
specified, both are written out, if the defaults are used, Info is written
out, but verbose is logged.

Ideally I'd like to tweak loggo so we can specify the call depth of the
caller, so we can grab the appropriate line numbers etc, but this can happen
later. Also, now any use of these methods will have the 'juju.cmd' module. Not
sure if we want to really parameterize that.

The only thing I'm wondering about is Stderr vs. Stdout.  Ideally I'd prefer
to use Stdout where possible, but for the format oriented commands, we still
want users to be able to go:
  'juju status --format=json | other-thing'
So we don't want to polute Stdout in those situations with output.

There are a number of options here:
 * we just write to Stdout, and have people add '-q'
 * we write the info and verbose info to Stderr so it just works

Then do we have some go to Stdout and some Stderr?

Logging now goes to Stderr, so we could just send all output there (except for
the actual formatted output).

https://code.launchpad.net/~thumper/juju-core/default-command-info/+merge/194061

(do not edit description out of merge proposal)

[thumper, 2013-11-06 04:04:42]

Please take a look.

[wallyworld, 2013-11-06 04:31:25]

A few questions.

1. -d for debug is sorta bad

There's a number of existing commands that use the -d option (eg for specifying
a directory) so I think we want to stcik with just --debug

2. Does it make sense to allow -q and --debug together?

If you want debug, then I think you would want everything else as well

3. show-log

I think if verbose is specified, that could turn on show-log. Do we still need
show-log? I'm not sure we do. For a user's perspective, I want to see either:

i. nothing at all except errors... option = "--quiet"
ii. informational lines that signpost where the command is up to as it executes
(without timestamps etc)... the default, option = ""
iii. verbose output with timestamps and some more detail... option = "--verbose"

As a developer, I also want:

iv. debug output with everything... option = "--debug"

I'm not sure with the above if show-log is still relevant.

As for the stdout vs stderr thing, I can see both sides. My initial view is that
stderr is for all log outout and stdout is for command results in json/yaml etc

https://codereview.appspot.com/22320043/diff/1/cmd/logging.go
File cmd/logging.go (right):

https://codereview.appspot.com/22320043/diff/1/cmd/logging.go#newcode77
cmd/logging.go:77: return fmt.Errorf(`"verbose" and "quiet" flags clash`)
perhaps 

"verbose" and "quiet" flags clash, please use one or the other, not both

[fwereade, 2013-11-06 10:44:31]

On 2013/11/06 04:04:42, thumper wrote:
> Please take a look.

I'm sure we want to keep informational messages to stderr. Still thinking about
the other points raised.

[jameinel, 2013-11-06 11:45:34]

We have a cmd.Context object which is passed to all the commands, and is
something that we can then pass into internal code.

It seems better to have it on an object, rather than as a package level
function.

does that make sense to you?

[fwereade, 2013-11-07 14:45:41]

On 2013/11/06 11:45:34, jameinel wrote:
> We have a cmd.Context object which is passed to all the commands, and is
> something that we can then pass into internal code.
> 
> It seems better to have it on an object, rather than as a package level
> function.
> 
> does that make sense to you?

That's actually starting to make more and more sense, because:

1) the value of this gets lower and lower as more functionality moves behind the
API -- it becomes more and more convenient to just write to the cmd.Context
that's right there in Run

2) bootstrap and (manual) add-machine feel like the major exceptions to the
above, but both of those need the context anyway for sudo (and given that we
probably ought not to be reading env vars directly, we probably ought to be
communicating those to bootstrap via some such context too).

What's the actual set of potential users for this code once the CLI talks API?

[thumper, 2014-03-26 00:48:18]

Please take a look.

[thumper, 2014-03-26 00:53:04]

On 2013/11/06 04:31:25, wallyworld wrote:
> A few questions.
> 
> 1. -d for debug is sorta bad
> 
> There's a number of existing commands that use the -d option (eg for
specifying
> a directory) so I think we want to stcik with just --debug

Removed -d

> 2. Does it make sense to allow -q and --debug together?
> 
> If you want debug, then I think you would want everything else as well

Yes -q and --debug is fine (IMO). In fact I force the fact, as if you say
--debug, by forcing -q we get all the info, and verbose output as log file
entries.

> 3. show-log
> 
> I think if verbose is specified, that could turn on show-log. Do we still need
> show-log? I'm not sure we do. For a user's perspective, I want to see either:
> 
> i. nothing at all except errors... option = "--quiet"
> ii. informational lines that signpost where the command is up to as it
executes
> (without timestamps etc)... the default, option = ""
> iii. verbose output with timestamps and some more detail... option =
"--verbose"
> 
> As a developer, I also want:
> 
> iv. debug output with everything... option = "--debug"
> 
> I'm not sure with the above if show-log is still relevant.

Perhaps not... but outside the scope of this for now.

> As for the stdout vs stderr thing, I can see both sides. My initial view is
that
> stderr is for all log outout and stdout is for command results in json/yaml
etc
> 
> https://codereview.appspot.com/22320043/diff/1/cmd/logging.go
> File cmd/logging.go (right):
> 
> https://codereview.appspot.com/22320043/diff/1/cmd/logging.go#newcode77
> cmd/logging.go:77: return fmt.Errorf(`"verbose" and "quiet" flags clash`)
> perhaps 
> 
> "verbose" and "quiet" flags clash, please use one or the other, not both

done

[thumper, 2014-03-26 00:53:19]

On 2013/11/06 10:44:31, fwereade wrote:
> On 2013/11/06 04:04:42, thumper wrote:
> > Please take a look.
> 
> I'm sure we want to keep informational messages to stderr. Still thinking
about
> the other points raised.

kept them on stderr

[thumper, 2014-03-26 00:54:10]

On 2013/11/06 11:45:34, jameinel wrote:
> We have a cmd.Context object which is passed to all the commands, and is
> something that we can then pass into internal code.
> 
> It seems better to have it on an object, rather than as a package level
> function.
> 
> does that make sense to you?

moved the methods to the context object.

I had originally thought that by having them as stand alone functions,
we wouldn't have to pass the context down to the places that are needing them.

Consider the bastardisation we have with loggers at the moment.

[wallyworld, 2014-03-26 01:07:18]

LGTM

https://codereview.appspot.com/22320043/diff/20001/cmd/cmd.go
File cmd/cmd.go (right):

https://codereview.appspot.com/22320043/diff/20001/cmd/cmd.go#newcode110
cmd/cmd.go:110: // the logger if we are.
....?
Doesn't quite parse