Agreements around juju.Conn

[David Cheney]

+1, this is what I would also like to see from juju.Conn, I will make it so. 

> 
> 2) juju.Conn should wrap command line functionality even when it's a
> single line being called. We went back and forth a few times on when
> we should have a method there or not, and it sounds fair to say that
> the current implementation is pretty good. That said, it's not very
> consistent in that we have certain features there, and others require
> direct state manipulation, without a clear line. The agreement
> establishes the line: if we have a subcommand with a given feature,
> that subcommand should be available in similar fashion (not
> necessarily the *exact* look & feel) in the juju.Conn implementation.
> Besides clarity, this means we have a nice library API for people to
> use juju from within Go, and also doubles as good documentation source
> for people that want to see how to find their way in the juju code
> base.

Exactly, and it is high level functionality that other tools that have yet to be written can use, rather than scrobbling about in the state.