extracts ksonnet generator to a new package to make it easier to incorporate in new code

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

Introduce `ks component rm <component>`. This functionality will:

1. Delete the component file from components/. This is determined by the
component file name. If there exists two files with the same name but
different file  extensions, we will error out.

2. Remove component references. This currently implies removing all
component referenes in the component/params.libsonnet file and the
environment-specific params.libsonnet files.

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

Dependencies in a ksonnet application are installed from collections of
packages called registries. In order to be precise about which packages
an app depends on, and where they are from, we have an API that
specifies each of these nouns.

Unfortunately, we never hooked up code to verify the versions of these
specifications as we deserialize them.

This commit will correct that.

Signed-off-by: Alex Clemmer <clemmer.alexander@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>

Consider the scenario where the user has two registries 'incubator', and
'incubatorXYZ' pointing to the same repository.

It might be confusing why running `ks pkg install incubatorXYZ/mysql`
fails if they ran `ks pkg install incubator/mysql` previously.

This is a small change to help users resolve that scenario by passing
the `--name` flag on install.

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

This adds a high level 'component' command and a 'component list'
command. 'component list' will pretty print all the components in
ksonnet application directory.

To accomplish this, an API is added to the metadata manager that returns
all components. Components are the individual files in /components, with
the path extension trimmed.

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

Currently the component APIs are grouped into the same file as
manager.go. As more component APIs are added, managers.go will be
difficult to maintain. Similar to the environment and registry APIs,
component APIs will be moved into a separate file component.go

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

This adds a high level 'component' command and a 'component list'
command. 'component list' will pretty print all the components in
ksonnet application directory.

To accomplish this, an API is added to the metadata manager that returns
all components. Components are the individual files in /components, with
the path extension trimmed.

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

Currently the component APIs are grouped into the same file as
manager.go. As more component APIs are added, managers.go will be
difficult to maintain. Similar to the environment and registry APIs,
component APIs will be moved into a separate file component.go

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

When a user adds a registry (e.g., through a command like `ks registry
add`, or implicitly through `ks init`) we must parse a URI pointing at
registry hosted on github.com, since we currently only support the
`"github"` protocol.

This logic is somewhat complex, since we must

  1. infer the location of a `registry.yaml` file given the URI, and
  2. accept and parse a broad set of URIs a user might provide.

For example, consider the following valid URIs, and what we do to infer
the location of the `registry.yaml` file that specifies a registry:

  URIs with an explicit `registry.yaml`:
    github.com/exampleOrg/exampleRepo/blob/master/registry.yaml
    github.com/exampleOrg/exampleRepo/blob/master/incubator/registry.yaml

  URIs with an implicit `registry.yaml`:
    github.com/exampleOrg/exampleRepo/
    github.com/exampleOrg/exampleRepo/tree/master

  URIs with different protocols (or no protocol specified)
    github.com/exampleOrg/exampleRepo
    http://github.com/exampleOrg/exampleRepo
    https://github.com/exampleOrg/exampleRepo


    www.github.com/exampleOrg/exampleRepo

And so on.

Because this parsing logic has many branches, it is important for us to
test every branch, so that the user is not surprised when a command like
`registry add` doesn't work.

This commit will introduce such tests.

Signed-off-by: Alex Clemmer <clemmer.alexander@gmail.com>

Currently users are unable to add their own registries through the CLI.
This limits them to a small subset of prototypes found in the default
incubator registry.

This commit will add the command `ks registry add`, that allows users to
add registries supporting the `github` protocol.

It will be of the form `ks registry add <registry-name> <registry-uri>
[--version]`. If a version is not specified, `latest` will be used.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.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>

It is possible for the walk function to be called with err set

Signed-off-by: Tanner Bruce <bruce.tanner@gmail.com>

Signed-off-by: Joe Beda <joe.github@bedafamily.com>

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

Currently, if a version is not provided to the following `pkg install`
command

`../ks pkg install incubator/redis`

, the following error will occur:

`ERROR GET
https://api.github.com/repos/ksonnet/parts/commits/incubator/redis

: 404
Not Found []`

This commit will pull in the latest package from master where the
version is not specified.

Also set the default repository ref to 'master' instead of 'test-reg'.

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

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

Currently the schema for the component/params.libsonnet file do not
support top-of-file imports. This change will allow support.

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

Currently absolute paths are being used for jsonnet imports. This makes
it difficult to share the files across different systems.

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

Currently, there are limitations around the file system we are using
that does not easily allow renaming of `us-west/prod` to `us-west`, or
vice versa - `us-west` to `us-west/prod`.

This commit will handle the logic to allow for that by moving the file
contents.

Currently, creating a `dev` environment will create a file
`dev.jsonnet`. Creating a `prod` environment will create a file
`prod.jsonnet`. This is a little more complex and prone to error than it
needs to be, especially when we are renaming environments. It will also
make this file easier to refer to in documentation if we give the file a
static name -- `main.jsonnet`.

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.

This commit will partially resolve #38.

A bug existed where if `param set` was called for the same param twice,
a duplicate entry was created for the component. This only occured where
the component name contained a special character.

Currently the env directory is being renamed on `env set foo
--name=bar`, however the `foo.jsonnet` file also needs to be renamed to
`bar.jsonnet`. This commit fixes that.

Fixes #48.

Currently the structs `app.Spec`, `registry.Spec`, and `parts.Spec` are
all serialized and deserialized using JSON instead of YAML.

This commit will resolve this issue.

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.

The ksonnet project exposes a "default" registry, `incubator`, in the
ksonnet/parts repository.

This commit will cause ever `ks init` command to automatically add this
registry to the ksonnet application.

The vast majority of ksonnet apps will know about at least one registry,
the official ksonnet `incubator` registry. In general, managing
registries can involve fairly complex logic (e.g., resolving a reference
to a registry to a remote registry specification; finding all
libraries exposed by a registry; and so on).

This commit will introduce the `registry.Manager` abstraction, as well
as an implementation for registries hosted as GitHub repositories.

When the user calls `ks init <whatever>`, we need to emit an `app.yaml`
for the new project. This commit will introduce such behavior.

Every ksonnet application has an `app.yaml`, which is similar in
principle to node.js's `package.json`. It contains important metadata,
such as description, names, and information about dependencies. This is
similarly true of `registry.yaml`, which contains information about a
package registry.

This commit will introduce schemas for both these files.

Pretty prints differences between the component parameters of two
environments.

A component flag is accepted to diff against a single component. By
default, the diff is performed against all components.

The goal of this commit is to add an interface to `metadata.Manager`
that allows retrieving of all environment params:
`getEnvironmentParams(envName)`.

This is done by:

1. Adding functionality to the snippet parser to get all environment
params out of the snippet read from
`environments/<env>/params.libsonnet`

2. Adding functionality to the snippet parser to get all component
params out of the snippet read from `components/params.libsonnet`

3. Having the `metadata.Manager` implementation handle the 'joining' of
params from 1) and 2), and returning that result.

This commit will add an interface `SetEnvironmentParams` to
metadata.Manager that allows setting of env params.

Also implements the logic for parsing the jsonnet snippet to
append / modify params in simple env param schemas. It will:

1. Update the params if the component exists in the jsonnet
snippet.
2. Add the component if it does not exist.

This commit will add an interface `GetComponentParams` to
metadata.Manager that returns a map of parameters for the passed in
component.

Also implements the logic for parsing the jsonnet snippet to retrieve
the parameters.

This functionality will later support new commands to list parameters.