$ juju switch --format

[Tim Penhey]

I think where people are getting confused is the relationship between
the various uses of the name environment.  We have more a language problem.

We currently use environment to mean several things:
 1) a running environment that has many users
 2) an entry in the environments.yaml file
 3) the name of a .jenv file in $JUJU_HOME/environments

You can quickly see where the confusion comes from.

In all cases where we are talking about "environments" from the command
line, what we are really talking about are environment/user pairs, and
that this pair is given a name, or alias that the user uses to refer to
that pair.

When the environment (the first meaning) is running, the user has a name
for it that is used for the .jenv file.  That file encapsulates the
identity of the running environment (through the uuid and also the api
endpoints).  When the environment (again the first meaning) isn't
running, then it only relates to the entry in the environments.yaml file
(which as I understand it, we want to get rid of eventually).

The main thrust of the proposal is to do the following:
 * "juju switch" has one and only one task, and that is to change
between user-aliases for environment/user pairs, and when the change is
made, it tells you that environment and user you are now using (and
maybe status[1])

 * "juju info" tells us information about our environments.  It does not
do remote calls to any environment, just gives a more friendly way to
query what .jenv files we have and what environments we have defined in
the environments.yaml file
   - yes we could have a 'juju info --name-only' or some other flag to
support the use case where people really do want to destroy their
current environment with out specifying exactly :-)

Tim



[1] status is inferred from the source: if using a jenv file, we assume
it is running, if from the environments.yaml it is "not running", and we
look for the .jenv file first.  I'd be happy to call this something
other than status