Use afero when possible to allow for fs flexibitily (in tests or other instances).

fixes #39

Signed-off-by: bryanl <bryanliles@gmail.com>

Partially implements the proposal
[here](https://github.com/ksonnet/ksonnet/blob/master/design/proposals/explicit-environment-metadata.md

)

Fixes #222

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: Levi Blackstone <levi.blackstone@rackspace.com>

Currently, if we run `param set guestbook-ui foo-bar x`,

The jsonnet snippet will write: `foo-bar: "x"`.

However, this is incorrect jsonnet syntax. This commit will fix this
issue, to instead write `"foo-bar": "x"`.

Also updates the `Get...` Param functions to return non-quoted
identifiers for prettier display.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: Jessica Yao <jessica@heptio.com>

Signed-off-by: Jessica Yao <jessica@heptio.com>

Currently, namespace and server is being overwritten by the environment
despite the user explicitly passing in the `--namespace` flag.

Ex: during `ks apply dev --namespace=ns2`, `ns2` should take preference
to the namespace specified by the dev environment.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Fixes #100.

This commit will transition the ksonnet CLI away from accepting either a
list of files or an environment (or both). A detailed explanation
follows.

Historically, the ksonnet CLI has had several "environment commands".
These commands (e.g., `apply`, `diff`, `delete`, `show`, etc.) all took
one of the following:

  1. An environment name. For example, `apply us-west/dev` will `apply`
     everything in the `components/` directory to the cluster denoted by
     `us-west/dev`.
  2. A set of files. For example, `apply -f foo.jsonnet -f bar.jsonnet`
     would apply those two specific Jsonnet files to the server
     specified by the current context in $KUBECONFIG.
  3. Both an environment name and a set of files. For example,
     `apply us-west/dev -f foo.jsonnet -f bar.jsonnet` would `apply`
     those two files to the cluster denoted by the `us-west/dev`
     environment.

This "duality" remained in place primarily because it was important for
the ksonnet CLI to maintain functional compatibility (though not strict
CLI-level app compatibility) with the kubecfg tool.

Some time ago the ksonnet CLI was forked from the kubecfg CLI, but it is
only in this commit that we abandon this duality. Specifically, this
commit will _require_ the environment name for all commands. For
example, the form of `apply` will now be:
`apply <env-name> [-f <file>]`.

There are main parts to this:

  1. Refactoring core abstractions that supports this "duality".
     Specifically, removing the `cmd.envSpec` type and several
     functions, such as `cmd.parseEnvCmd`.
  2. Updating the tests to reflect this new directory structure.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

If the namespace is not provided in the target kubeconfig context, use
'default'.

Also squashes a bug where the namespace, server flags may have been
ignored during init.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

- Add message:  Creating a new app 'foo' at path '/path/to/foo'
- On success, add message:  ksonnet app successfully created! Next, try
  creating a component with `ks generate`
- On failure, provide suggestions for the user.
- Make note that the context is retrieved from the kubeconfig file at
  the environment variable $KUBECONFIG

In line 161 of `root.go`, we're failing to check whether a cluster in
the $KUBECONFIG clusters array exists before using it. This will cause a
`nil` dereference error.

As part of the environments feature, we want to be able to deploy to a
specific cluster given the environment's URI. We cross-check against
kubecfg for this URI's location. For fail-safe comparison, we probably
want to normalize these URIs.

Currently, ExtCodes are only provided when the 'env' flag is present in
commands. The result is errors occuring when we run commands such as `ks
show default -f components/guestbook-ui.jsonnet`, where the params
ExtVar is needed. This commit fixes that scenario.

Currently, if a component name contains a special character, ex:
foo-bar, this translates to the jsonnet identifier: foo-bar, which is
invalid syntax.

This change will quote component names where there are special
characters.

This resolves the first half of #68. When we `generate` using a
prototype from a vendored dependency, it often results in a compilation
error when we `apply`, because these prototypes usually depend on code
that exists in the dependency, and `vendor/` is not a part of the
Jsonnet search path.

This commit resolves this problem by adding it to the search path.

This fixes the bug where objects weren't being deployed to the cluster
specified by the environment. This bug occurred because overrides (ex:
cluster, namespace) were being lost because we weren't applying the
changes to the correct override object. To fix this, we needed to pass
the overrides by reference.

Expose the import path to environments/:env/params.libsonnet as an
ExtCode so that it is made accessible to component files during
expansion.

'server' is consistent with what is used by clientgo. 'uri' only
introduces new language to ksonnet with the same meaning.

This change enables the user to diff between two environments that are
either local or remote.

i.e.,

`kubecfg diff local:dev local:prod` will diff between the expanded
templates for each environment on disk.

`kubecfg diff remote:dev remote:prod` will diff between two remote
environment clusters. It does this by first expanding the component
templates of each environment. Then, the live objects are fetched from
each of the clusters and the diff is performed against the live objects.

`kubecfg diff local:dev remote:prod` is also an option. This will diff
between the expanded templates for 'dev' on disk and the live objects
on 'prod's server.

`ks env set foo --namespace=""` and `ks env add foo` will both set the
namespace to 'default' in the environment's spec.json file.

`ks env add myenv --context=dev` will initialize the environment URI
and namespace based on the context `dev`, as specfied in the
kubeconfig file. The same applies for `ks init foo --context=dev`.

If both the context and uri argument is not provided, the current
context is used.

This change will also remove uri as a mandatory arg in `ks env add`.
The uri will be moved to a flag. It cannot be used at the same time as
`context`.

Environments currently have the concept of a server URI, but it is
ambiguous which cluster namespace to use.

This commit will introduce the concept of namespaces to the env
commands.

For example,
`kubecfg env add staging http://mock-staging-uri \
 --namespace=staging-namespace`
`kubecfg env set staging --namespace=staging-namespace`

The default environment will use the namespace of the default context.

This commit will also update commands that take the <env> arg such as
`apply` to make use of the env namespace, if specified.

Commands that take `env` as a param currently expand all files in the
`components` directory. This is no longer necessary with the
introduction of `base.libsonnet` and the per-environment override
`<env>.jsonnet` file.

This commit will simply expand the single `<env>.jsonnet` file (which
will implicitly expand all component files). The case of running
`ksonnet apply default`, is equivalent to running `ksonnet apply -f
environments/default/default.jsonnet`.

base.libsonnet is a generated file that exists at the root of the
environments directory. This file is generated for all ksonnet projects.
The main goal of this file is to import all components in the components
directory, so that environments are able to easily extend / override any
one of these components in a modular structure.

The `clientConfig` param currently being passed is not needed, because
it exists as a package level var in root. It also makes little sense to
pass a custom `clientConfig` because if `overrides.Context.Namespace` is
populated, the namespace that is returned is configured as an override
in the package level `clientConfig` and not the `clientConfig` in the
param.

In order to support environment heirarchy, we need to be able to
reference all components. This commit will implement component imports
as k-v pairs ex: foo: "import/foo.jsonnet" as a Jsonnet object. This
jsonnet object will then be assigned as an ExtCode so that it can be
referenced by a base.libsonnet file which environments can build /
override upon.

Fixes #108.

Currently if we use a command like `apply default -f
components/whatever.yaml`, kubecfg will fail to emit flags that add
ksonnet-lib to the -J paths. This means that, while a command like
`apply default` will correctly linke against (e.g.) `k.libsonnet`,
adding the `-f` flag will not.

This commit will correct this problem for all commands of this form.

For example, 'apply <env' currently operates as a no-op. With the
introduction of simple environments in PR #131, 'apply <env>' should
perform basic validation such that:

1. The user has added the environment that is being deployed against to
their Ksonnet project.

2. The URI in the environment's spec file that the user wishes to deploy
to should correspond to at least one cluster location as listed in
kubeconfig.

If either of those conditions are not satisfied, the kubecfg user will
receive the corresponding error.

In addition, this commit will set the kubectl --cluster flag to point at
the cluster listed by the environment URI.

Currently, commands take either an <env> or a '-f' argument but not
both. With this commit, we are allowing both args to be provided. The
behavior is expand the files passed by the '-f' flag and deploy the
objects to <env>.

Currently 'Info' level logs are only shown with the '-v' flag. This
makes commands without the '-v' flag of little use to users, especially
on success cases, due to no output.

This commit will set the default log level to 'Info', and passing a '-v'
flag will log at a 'Debug' level.

'env set <name>' sets environment fields such as the name, and cluster
URI. It currently accepts the flags '--name' and '--uri'. Changing the
name of an environment will also update the directory structure in
'environments'.

This commit will remove the vendor/lib and vendor/schema directories
generated by 'init'. An 'environments' directory will be created from
the root app directory, with the default environment directory 'dev'
and it's containing contents rooted at 'environments'.

The intention of environments are to represent the deployment
environments of Kubernete clusters, with the following example
directory structure:

app-name/
  ..
  envs/
    dev/
    us-west/
      prod/
      staging/

This commit is a follow-up to the discussion in the ksonnet.next design
doc, in which users consistently expressed their preference that the
`update` command be called `apply`.

NOTE: We have renamed `pkg/kubecfg/update_test.go` ->
`pkg/kubecfg/apply_test.go`, but we copy the `update`'s integration test
file. The reason is that the `update` unit tests actually test things
like GC (rather than the command itself), so the file name is
inconsequential. On the other hand, the integration tests test the
commands themselves, so it is important to have two copies, one for
`update` and one for `apply`.

Currently, if the user wants to deploy a ksonnet application, and that
application uses some vendored library, or something in the `lib/`
directory, they will have to pass the appropriate `-J` flags into the
command themselves.

This commit will automatically add these whenever we're in an app
directory and a command is issued. In particular, even if the user
passes in the `-f` flag (rather than an environment name), we'll still
add library paths to the command if we're in a ksonnet app directory.
This is meant to capture the case that a user wants to update one
resource in particular in a ksonnet application.

If the current kubeconfig context is declared with an
explicit (non-empty) namespace, then `mergedKubeConfig.Namespace()`
returns that *config file* namespace value, ignoring an explicit
`--namespace` command line flag.

See https://github.com/kubernetes/client-go/issues/288 for upstream
client-go bug/discussion.

This change works around the issue by just checking the Namespace
override ourselves before falling through to the regular function.

Further fixes #103