Manage your golang vendor and vendored packages with ease. Inspired by tools like Maven, Bundler, and Pip.

# Glide: Vendor Package Management for Golang

![glide logo](https://glide.sh/assets/logo-small.png)

Are you used to tools such as Cargo, npm, Composer, Nuget, Pip, Maven, Bundler,
or other modern package managers? If so, Glide is the comparable Go tool.

*Manage your vendor and vendored packages with ease.* Glide is a tool for
managing the `vendor` directory within a Go package. This feature, first
introduced in Go 1.5, allows each package to have a `vendor` directory
containing dependent packages for the project. These vendor packages can be
installed by a tool (e.g. glide), similar to `go get` or they can be vendored and
distributed with the package.

[![Build Status](https://travis-ci.org/Masterminds/glide.svg)](https://travis-ci.org/Masterminds/glide)
[![Build status](https://ci.appveyor.com/api/projects/status/3pl4ytgdlfj852li?svg=true&passingText=windows%20build%20passing&failingText=windows%20build%20failing)](https://ci.appveyor.com/project/mattfarina/glide-a8xtg)
[![Go Report Card](https://goreportcard.com/badge/github.com/Masterminds/glide)](https://goreportcard.com/report/github.com/Masterminds/glide) [![GoDoc](https://godoc.org/github.com/Masterminds/glide?status.svg)](https://godoc.org/github.com/Masterminds/glide) [![Documentation Status](https://readthedocs.org/projects/glide/badge/?version=stable)](http://glide.readthedocs.org/en/stable/?badge=stable) [![Documentation Status](https://readthedocs.org/projects/glide/badge/?version=latest)](http://glide.readthedocs.org/en/latest/?badge=latest)

### Go Modules

The Go community is now using Go Modules to handle dependencies. Please consider
using that instead of Glide. Glide is now mostly unmaintained.

### Features

* Ease dependency management
* Support **versioning packages** including [Semantic Versioning
  2.0.0](http://semver.org/) support. Any constraint the [`github.com/Masterminds/semver`](https://github.com/Masterminds/semver)
  package can parse can be used.
* Support **aliasing packages** (e.g. for working with github forks)
* Remove the need for munging import statements
* Work with all of the `go` tools
* Support the VCS tools that Go supports:
    - git
    - bzr
    - hg
    - svn
* Support custom local and global plugins (see docs/plugins.md)
* Repository caching and data caching for improved performance.
* Flatten dependencies resolving version differences and avoiding the inclusion
  of a package multiple times.
* Manage and install dependencies on-demand or vendored in your version control
  system.

## How It Works

Glide scans the source code of your application or library to determine the needed
dependencies. To determine the versions and locations (such as aliases for forks)
Glide reads a `glide.yaml` file with the rules. With this information Glide retrieves
needed dependencies.

When a dependent package is encountered its imports are scanned to determine
dependencies of dependencies (transitive dependencies). If the dependent project
contains a `glide.yaml` file that information is used to help determine the
dependency rules when fetching from a location or version to use. Configuration
from Godep, GB, GOM, and GPM is also imported.

The dependencies are exported to the `vendor/` directory where the `go` tools
can find and use them. A `glide.lock` file is generated containing all the
dependencies, including transitive ones.

The `glide init` command can be use to setup a new project, `glide update`
regenerates the dependency versions using scanning and rules, and `glide install`
will install the versions listed in the `glide.lock` file, skipping scanning,
unless the `glide.lock` file is not found in which case it will perform an update.

A project is structured like this:

```
- $GOPATH/src/myProject (Your project)
  |
  |-- glide.yaml
  |
  |-- glide.lock
  |
  |-- main.go (Your main go code can live here)
  |
  |-- mySubpackage (You can create your own subpackages, too)
  |    |
  |    |-- foo.go
  |
  |-- vendor
       |-- github.com
            |
            |-- Masterminds
                  |
                  |-- ... etc.
```

*Take a look at [the Glide source code](http://github.com/Masterminds/glide)
to see this philosophy in action.*

## Install

The easiest way to install the latest release on Mac or Linux is with the following script:

```
curl https://glide.sh/get | sh
```

On Mac OS X you can also install the latest release via [Homebrew](https://github.com/Homebrew/homebrew):

```
$ brew install glide
```

On Ubuntu Precise (12.04), Trusty (14.04), Wily (15.10) or Xenial (16.04) you can install from our PPA:

```
sudo add-apt-repository ppa:masterminds/glide && sudo apt-get update
sudo apt-get install glide
```

On Ubuntu Zesty (17.04) the package is called `golang-glide`.

[Binary packages](https://github.com/Masterminds/glide/releases) are available for Mac, Linux and Windows.

For a development version it is also possible to `go get github.com/Masterminds/glide`.

To build from source you can:

1. Clone this repository into `$GOPATH/src/github.com/Masterminds/glide` and
   change directory into it
2. If you are using Go 1.5 ensure the environment variable GO15VENDOREXPERIMENT is set, for
   example by running `export GO15VENDOREXPERIMENT=1`. In Go 1.6 it is enabled by default and
   in Go 1.7 it is always enabled without the ability to turn it off.
3. Run `make build`

This will leave you with `./glide`, which you can put in your `$PATH` if
you'd like. (You can also take a look at `make install` to install for
you.)

The Glide repo has now been configured to use glide to
manage itself, too.

## Usage

```
$ glide create                            # Start a new workspace
$ open glide.yaml                         # and edit away!
$ glide get github.com/Masterminds/cookoo # Get a package and add to glide.yaml
$ glide install                           # Install packages and dependencies
# work, work, work
$ go build                                # Go tools work normally
$ glide up                                # Update to newest versions of the package
```

Check out the `glide.yaml` in this directory, or examples in the `docs/`
directory.

### glide create (aliased to init)

Initialize a new workspace. Among other things, this creates a `glide.yaml` file
while attempting to guess the packages and versions to put in it. For example,
if your project is using Godep it will use the versions specified there. Glide
is smart enough to scan your codebase and detect the imports being used whether
they are specified with another package manager or not.

```
$ glide create
[INFO]	Generating a YAML configuration file and guessing the dependencies
[INFO]	Attempting to import from other package managers (use --skip-import to skip)
[INFO]	Scanning code to look for dependencies
[INFO]	--> Found reference to github.com/Masterminds/semver
[INFO]	--> Found reference to github.com/Masterminds/vcs
[INFO]	--> Found reference to github.com/codegangsta/cli
[INFO]	--> Found reference to gopkg.in/yaml.v2
[INFO]	Writing configuration file (glide.yaml)
[INFO]	Would you like Glide to help you find ways to improve your glide.yaml configuration?
[INFO]	If you want to revisit this step you can use the config-wizard command at any time.
[INFO]	Yes (Y) or No (N)?
n
[INFO]	You can now edit the glide.yaml file. Consider:
[INFO]	--> Using versions and ranges. See https://glide.sh/docs/versions/
[INFO]	--> Adding additional metadata. See https://glide.sh/docs/glide.yaml/
[INFO]	--> Running the config-wizard command to improve the versions in your configuration
```

The `config-wizard`, noted here, can be run here or manually run at a later time.
This wizard helps you figure out versions and ranges you can use for your
dependencies.

### glide config-wizard

This runs a wizard that scans your dependencies and retrieves information on them
to offer up suggestions that you can interactively choose. For example, it can
discover if a dependency uses semantic versions and help you choose the version
ranges to use.

### glide get [package name]

You can download one or more packages to your `vendor` directory and have it added to your
`glide.yaml` file with `glide get`.

```
$ glide get github.com/Masterminds/cookoo
```

When `glide get` is used it will introspect the listed package to resolve its
dependencies including using Godep, GPM, Gom, and GB config files.

### glide update (aliased to up)

Download or update all of the libraries listed in the `glide.yaml` file and put
them in the `vendor` directory. It will also recursively walk through the
dependency packages to fetch anything that's needed and read in any configuration.

```
$ glide up
```

This will recurse over the packages looking for other projects managed by Glide,
Godep, gb, gom, and GPM. When one is found those packages will be installed as needed.

A `glide.lock` file will be created or updated with the dependencies pinned to
specific versions. For example, if in the `glide.yaml` file a version was
specified as a range (e.g., `^1.2.3`) it will be set to a specific commit id in
the `glide.lock` file. That allows for reproducible installs (see `glide install`).

To remove any nested `vendor/` directories from fetched packages see the `-v` flag.

### glide install

When you want to install the specific versions from the `glide.lock` file use
`glide install`.

```
$ glide install
```

This will read the `glide.lock` file and install the commit id specific versions
there.

When the `glide.lock` file doesn't tie to the `glide.yaml` file, such as there
being a change, it will provide a warning. Running `glide up` will recreate the
`glide.lock` file when updating the dependency tree.

If no `glide.lock` file is present `glide install` will perform an `update` and
generate a lock file.

To remove any nested `vendor/` directories from fetched packages see the `-v` flag.

## glide novendor (aliased to nv)

When you run commands like `go test ./...` it will iterate over all the
subdirectories including the `vendor` directory. When you are testing your
application you may want to test your application files without running all the
tests of your dependencies and their dependencies. This is where the `novendor`
command comes in. It lists all of the directories except `vendor`.

    $ go test $(glide novendor)

This will run `go test` over all directories of your project except the
`vendor` directory.

## glide name

When you're scripting with Glide there are occasions where you need to know
the name of the package you're working on. `glide name` returns the name of the
package listed in the `glide.yaml` file.

### glide tree

Glide includes a few commands that inspect code and give you details
about what is imported. `glide tree` is one such command. Running it
gives data like this:

```
$ glide tree
github.com/Masterminds/glide
	github.com/Masterminds/cookoo   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo)
		github.com/Masterminds/cookoo/io   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/io)
	github.com/Masterminds/glide/cmd   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/cmd)
		github.com/Masterminds/cookoo   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo)
			github.com/Masterminds/cookoo/io   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/io)
		github.com/Masterminds/glide/gb   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/gb)
		github.com/Masterminds/glide/util   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/util)
			github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
		github.com/Masterminds/glide/yaml   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/yaml)
			github.com/Masterminds/glide/util   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/util)
				github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
			github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
			gopkg.in/yaml.v2   (/Users/mfarina/Code/go/src/gopkg.in/yaml.v2)
		github.com/Masterminds/semver   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/semver)
		github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
		github.com/codegangsta/cli   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/codegangsta/cli)
	github.com/codegangsta/cli   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/codegangsta/cli)
	github.com/Masterminds/cookoo   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo)
		github.com/Masterminds/cookoo/io   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/io)
	github.com/Masterminds/glide/gb   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/gb)
	github.com/Masterminds/glide/util   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/util)
		github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
	github.com/Masterminds/glide/yaml   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/yaml)
		github.com/Masterminds/glide/util   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/util)
			github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
		github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
		gopkg.in/yaml.v2   (/Users/mfarina/Code/go/src/gopkg.in/yaml.v2)
	github.com/Masterminds/semver   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/semver)
	github.com/Masterminds/vcs   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs)
	github.com/codegangsta/cli   (/Users/mfarina/Code/go/src/github.com/Masterminds/glide/vendor/github.com/codegangsta/cli)
```

This shows a tree of imports, excluding core libraries. Because
vendoring makes it possible for the same package to live in multiple
places, `glide tree` also prints the location of the package being
imported.

_This command is deprecated and will be removed in the near future._

### glide list

Glide's `list` command shows an alphabetized list of all the packages
that a project imports.

```
$ glide list
INSTALLED packages:
	vendor/github.com/Masterminds/cookoo
	vendor/github.com/Masterminds/cookoo/fmt
	vendor/github.com/Masterminds/cookoo/io
	vendor/github.com/Masterminds/cookoo/web
	vendor/github.com/Masterminds/semver
	vendor/github.com/Masterminds/vcs
	vendor/github.com/codegangsta/cli
	vendor/gopkg.in/yaml.v2
```

### glide help

Print the glide help.

```
$ glide help
```

### glide --version

Print the version and exit.

```
$ glide --version
glide version 0.12.0
```

### glide.yaml

For full details on the `glide.yaml` files see [the documentation](https://glide.sh/docs/glide.yaml).

The `glide.yaml` file does two critical things:

1. It names the current package
2. It declares external dependencies

A brief `glide.yaml` file looks like this:

```yaml
package: github.com/Masterminds/glide
import:
  - package: github.com/Masterminds/semver
  - package: github.com/Masterminds/cookoo
    version: ^1.2.0
    repo: git@github.com:Masterminds/cookoo.git
```

The above tells `glide` that...

1. This package is named `github.com/Masterminds/glide`
2. That this package depends on two libraries.

The first library exemplifies a minimal package import. It merely gives
the fully qualified import path.

When Glide reads the definition for the second library, it will get the repo
from the source in `repo`, checkout the latest version between 1.2.0 and 2.0.0,
and put it in `github.com/Masterminds/cookoo` in the `vendor` directory. (Note
that `package` and `repo` can be completely different)

**TIP:** The version is either VCS dependent and can be anything that can be checked
out or a semantic version constraint that can be parsed by the [`github.com/
Masterminds/semver`](https://github.com/Masterminds/semver) package.
For example, with Git this can be a branch, tag, or hash. This varies and
depends on what's supported in the VCS.

**TIP:** In general, you are advised to use the *base package name* for
importing a package, not a subpackage name. For example, use
`github.com/kylelemons/go-gypsy` and not
`github.com/kylelemons/go-gypsy/yaml`.

## Supported Version Control Systems

The Git, SVN, Mercurial (Hg), and Bzr source control systems are supported. This
happens through the [vcs package](https://github.com/masterminds/vcs).

## Frequently Asked Questions (F.A.Q.)

#### Q: Why does Glide have the concept of sub-packages when Go doesn't?

In Go every directory is a package. This works well when you have one repo
containing all of your packages. When you have different packages in different
VCS locations things become a bit more complicated. A project containing a
collection of packages should be handled with the same information including
the version. By grouping packages this way we are able to manage the related
information.

#### Q: bzr (or hg) is not working the way I expected. Why?

These are works in progress, and may need some additional tuning. Please
take a look at the [vcs package](https://github.com/masterminds/vcs). If you
see a better way to handle it please let us know.

#### Q: Should I check `vendor/` into version control?

That's up to you. It's not necessary, but it may also cause you extra
work and lots of extra space in your VCS. There may also be unforeseen errors
([see an example](https://github.com/mattfarina/golang-broken-vendor)).

#### Q: How do I import settings from GPM, Godep, gom or gb?

There are two parts to importing.

1. If a package you import has configuration for GPM, Godep, gom or gb Glide will
   recursively install the dependencies automatically.
2. If you would like to import configuration from GPM, Godep, gom or gb to Glide see
   the `glide import` command. For example, you can run `glide import godep` for
   Glide to detect the projects Godep configuration and generate a `glide.yaml`
   file for you.

Each of these will merge your existing `glide.yaml` file with the
dependencies it finds for those managers, and then emit the file as
output. **It will not overwrite your glide.yaml file.**

You can write it to file like this:

```
$ glide import godep -f glide.yaml
```

#### Q: Can Glide fetch a package based on OS or Arch?

A: Yes. Using the `os` and `arch` fields on a `package`, you can specify
which OSes and architectures the package should be fetched for. For
example, the following package will only be fetched for 64-bit
Darwin/OSX systems:

```yaml
- package: some/package
  os:
    - darwin
  arch:
    - amd64
```

The package will not be fetched for other architectures or OSes.

## LICENSE

This package is made available under an MIT-style license. See
LICENSE.txt.

## Thanks!

We owe a huge debt of gratitude to the [GPM and
GVP](https://github.com/pote/gpm) projects, which
inspired many of the features of this package. If `glide` isn't the
right Go project manager for you, check out those.

The Composer (PHP), npm (JavaScript), and Bundler (Ruby) projects all
inspired various aspects of this tool, as well.

## The Name

Aside from being catchy, "glide" is a contraction of "Go Elide". The
idea is to compress the tasks that normally take us lots of time into a
just a few seconds.


glide

dependency tool for go, godep helps build packages reproducibly by fixing their dependencies.

# Godep - Archived

Please use [dep](https://github.com/golang/dep) or another tool instead.

The rest of this readme is preserved for those that may still need its contents.

[![Build Status](https://travis-ci.org/tools/godep.svg)](https://travis-ci.org/tools/godep)

[![GoDoc](https://godoc.org/github.com/tools/godep?status.svg)](https://godoc.org/github.com/tools/godep)

godep helps build packages reproducibly by fixing their dependencies.

This tool assumes you are working in a standard Go workspace, as described [here](http://golang.org/doc/code.html). We
expect godep to build on Go 1.4* or newer, but you can use it on any project that works with Go 1 or newer.

Please check the [FAQ](FAQ.md) if you have a question.

## Golang Dep

The Go community now has the [dep](https://github.com/golang/dep) project to
manage dependencies. Please consider trying to migrate from Godep to dep. If there
is an issue preventing you from migrating please file an issue with dep so the
problem can be corrected. Godep will continue to be supported for some time but
is considered to be in a state of support rather than active feature development.

## Install

```console
go get github.com/tools/godep
```

## How to use godep with a new project

Assuming you've got everything working already, so you can build your project
with `go install` and test it with `go test`, it's one command to start using:

```console
godep save
```

This will save a list of dependencies to the file `Godeps/Godeps.json` and copy
their source code into `vendor/` (or `Godeps/_workspace/` when using older
versions of Go). Godep does **not copy**:

- files from source repositories that are not tracked in version control.
- `*_test.go` files.
- `testdata` directories.
- files outside of the go packages.

Godep does not process the imports of `.go` files with either the `ignore`
or `appengine` build tags.

Test files and testdata directories can be saved by adding `-t`.

Read over the contents of `vendor/` and make sure it looks reasonable. Then
commit the `Godeps/` and `vendor/` directories to version control.

## The deprecated `-r` flag

For older versions of Go, the `-r` flag tells save to automatically rewrite
package import paths. This allows your code to refer directly to the copied
dependencies in `Godeps/_workspace`. So, a package C that depends on package
D will actually import `C/Godeps/_workspace/src/D`. This makes C's repo
self-contained and causes `go get` to build C with the right version of all
dependencies.

If you don't use `-r`, when using older version of Go, then in order to use the
fixed dependencies and get reproducible builds, you must make sure that **every
time** you run a Go-related command, you wrap it in one of these two ways:

- If the command you are running is just `go`, run it as `godep go ...`, e.g.
  `godep go install -v ./...`
- When using a different command, set your `$GOPATH` using `godep path` as
  described below.

`-r` isn't necessary with go1.6+ and isn't allowed.

## Additional Operations

### Restore

The `godep restore` installs the
package versions specified in `Godeps/Godeps.json` to your `$GOPATH`. This
modifies the state of packages in your `$GOPATH`. NOTE: `godep restore` leaves
git repositories in a detached state. `go1.6`+ no longer checks out the master
branch when doing a `go get`, see [here](https://github.com/golang/go/commit/42206598671a44111c8f726ad33dc7b265bdf669).

> If you run `godep restore` in your main `$GOPATH` `go get -u` will fail on packages that are behind master.

Please see the [FAQ](https://github.com/tools/godep/blob/master/FAQ.md#should-i-use-godep-restore) section about restore.

### Edit-test Cycle

1. Edit code
1. Run `godep go test`
1. (repeat)

### Add a Dependency

To add a new package foo/bar, do this:

1. Run `go get foo/bar`
1. Edit your code to import foo/bar.
1. Run `godep save` (or `godep save ./...`).

### Update a Dependency

To update a package from your `$GOPATH`, do this:

1. Run `go get -u foo/bar`
1. Run `godep update foo/bar`.

You can use the `...` wildcard, for example `godep update foo/...`. Before comitting the change, you'll probably want to
inspect the changes to Godeps, for example with `git diff`, and make sure it looks reasonable.

## Multiple Packages

If your repository has more than one package, you're probably accustomed to
running commands like `go test ./...`, `go install ./...`, and `go fmt ./...`.
Similarly, you should run `godep save ./...` to capture the dependencies of all
packages in your application.

## File Format

Godeps is a json file with the following structure:

```go
type Godeps struct {
  ImportPath   string
  GoVersion    string   // Abridged output of 'go version'.
  GodepVersion string   // Abridged output of 'godep version'
  Packages     []string // Arguments to godep save, if any.
  Deps         []struct {
    ImportPath string
    Comment    string // Description of commit, if present.
    Rev        string // VCS-specific commit ID.
  }
}
```

Example Godeps:

```json
{
  "ImportPath": "github.com/kr/hk",
  "GoVersion": "go1.6",
  "Deps": [
    {
      "ImportPath": "code.google.com/p/go-netrc/netrc",
      "Rev": "28676070ab99"
    },
    {
      "ImportPath": "github.com/kr/binarydist",
      "Rev": "3380ade90f8b0dfa3e363fd7d7e941fa857d0d13"
    }
  ]
}
```

## Migrating to vendor/

Godep supports the Go 1.5+ vendor/
[experiment](https://github.com/golang/go/commit/183cc0cd41f06f83cb7a2490a499e3f9101befff)
utilizing the same environment variable that the go tooling itself supports
(`GO15VENDOREXPERIMENT`).

godep mostly works the same way as the `go` command line tool. If you have go
1.5.X and set `GO15VENDOREXPERIMENT=1` or have go1.6.X (or devel) `vendor/`
is enabled. **Unless** you already have a `Godeps/_workspace`. This is a safety
feature and godep warns you about this.

When `vendor/` is enabled godep will write the vendored code into the top level
`./vendor/` directory. A `./Godeps/Godeps.json` file is created to track
the dependencies and revisions. `vendor/` is not compatible with rewrites.

There is currently no automated migration between the old Godeps workspace and
the vendor directory, but the following steps should work:

```term
# just to be safe
$ unset GO15VENDOREXPERIMENT

# restore currently vendored deps to the $GOPATH
$ godep restore

# The next line is only needed to automatically undo rewritten imports that were
# created with godep save -r.
$ godep save -r=false <pkg spec>

# Remove the old Godeps folder
$ rm -rf Godeps

# If on go1.5.X to enable `vendor/`
$ export GO15VENDOREXPERIMENT=1

# re-analyze deps and save to `vendor/`.
$ godep save <pkg spec>

# Add the changes to your VCS
$ git add -A . ; git commit -am "Godep workspace -> vendor/"

# You should see your Godeps/_workspace/src files "moved" to vendor/.
```

## Releasing

1. Increment the version in `version.go`.
1. Tag the commit with the same version number.
1. Update `Changelog.md`.


godep

gom - Go Manager
================

[![Build Status](https://travis-ci.org/mattn/gom.png?branch=master)](https://travis-ci.org/mattn/gom)

Why
---

The `go get` command is useful. But we want to fix the problem where package versions are different from the latest update.
Are you going to do `go get -tags=1.1 ...`, `go get -tag=0.3` for each of them? We want to freeze package version.
Ruby's bundle is awesome.

Installation
------------

    go get github.com/mattn/gom

Gomfile
-------

    gom 'github.com/mattn/go-runewidth', :tag => 'go1'
    gom 'github.com/mattn/go-scan', :commit => 'ecb144fb1f2848a24ebfdadf8e64380406d87206'
    gom 'github.com/daviddengcn/go-colortext'
    gom 'github.com/mattn/go-ole', :goos => 'windows'

    # Execute only in the "test" environment.
    group :test do
        gom 'github.com/mattn/go-sqlite3'
    end

    # Execute only for the "custom_group" group.
    group :custom_group do
        gom 'github.com/golang/lint/golint'
    end
    
By default `gom install` install all packages, except those in the listed groups.
You can install packages from groups based on the environment using flags (`development`, `test` & `production`) : `gom -test install`

Custom groups my be specified using the -groups flag : `gom -test -groups=custom_group,special install`

Usage
-----

Create \_vendor directory and bundle packages into it

    gom install

Build on current directory with \_vendor packages

    gom build

Run tests on current directory with \_vendor packages

    gom test

Generate .travis.yml that uses `gom test`

    gom gen travis-yml

You can always change the name relative to the current `$GOPATH` directory using an environment variable: `GOM_VENDOR_NAME`

```bash
$ # to use a regular $GOPATH/src folder you should specify GOM_VENDOR_NAME equal '.'
$ GOM_VENDOR_NAME=. gom <command>
```

Tutorial
--------

Writing Gomfile and bundle

    $ ls
    main.go

    $ gom gen gomfile

    $ cat Gomfile
    gom 'github.com/daviddengcn/go-colortext'
    gom 'github.com/mattn/go-runewidth'

    $ gom install
    installing github.com/daviddengcn/go-colortext
    installing github.com/mattn/go-runewidth

    $ find \_vendor/src -maxdepth 2
    \_vendor/src
    \_vendor/src/github.com
    \_vendor/src/github.com/daviddengcn
    \_vendor/src/github.com/mattn

    $ gom build

If you want to bundle specified tag, branch or commit

    gom 'github.com/mattn/go-runewidth', :tag => 'tag_name'
    gom 'github.com/mattn/go-runewidth', :branch => 'branch_name'
    gom 'github.com/mattn/go-runewidth', :commit => 'commit_name'
    
If you want to bundle a repository that `go get` can't access

    gom 'github.com/username/repository', :command => 'git clone http://example.com/repository.git'

If you want to change local repository directory with command 'git clone', also skipdep and insecure, which is useful in internal network environment.

    gom 'github.com/username/repository', :private => 'true', :target => 'repository', :insecure=>'true', :skipdep=>'true' 

Todo
----

* Documentation

Author
------

Yasuhiro Matsumoto mattn.jp@gmail.com

License
-------

MIT: http://mattn.mit-license.org/2013


Simple dependency manager for Go (golang), inspired by Bundler.

Goop
====

![Goopie](https://raw.githubusercontent.com/nitrous-io/goop/master/goopie.png)

A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess with your `GOPATH`.

### Getting Started

1. Install Goop: `go get github.com/nitrous-io/goop`

2. Create `Goopfile`. Revision reference (e.g. Git SHA hash) is optional, but recommended. Prefix hash with `#`. (This is to futureproof the file format.)

   Example:
   ```
   github.com/mattn/go-sqlite3
   github.com/gorilla/context #14f550f51af52180c2eefed15e5fd18d63c0a64a
   github.com/dotcloud/docker/pkg/proxy #v1.0.1 // comment
   github.com/gorilla/mux !git@github.com:nitrous-io/mux.git // override repo url
   ```

3. Run `goop install`. This will install packages inside a subdirectory called `.vendor` and create `Goopfile.lock`, recording exact versions used for each package and its dependencies. Subsequent `goop install` runs will ignore `Goopfile` and install the versions specified in `Goopfile.lock`. You should check this file in to your source version control. It's a good idea to add `.vendor` to your version control system's ignore settings (e.g. `.gitignore`).

4. Run commands using `goop exec` (e.g. `goop exec make`). This will execute your command in an environment that has correct `GOPATH` and `PATH` set.

5. Go commands can be run without the `exec` keyword (e.g. `goop go test`).

### Other commands

* Run `goop update` to ignore an existing `Goopfile.lock`, and update to latest versions of packages (as specified in `Goopfile`).

* Running `eval $(goop env)` will modify `GOPATH` and `PATH` in current shell session, allowing you to run commands without `goop exec`.

### Caveat

Goop currently only supports Git and Mercurial. This should be fine for 99% of the cases, but you are more than welcome to make a pull request that adds support for Subversion and Bazaar.

- - -
[Work on awesome golang projects, like Goop, at Nitrous.IO](http://www.nitrous.io/jobs/?utm_source=nitrous.io&utm_medium=goop_readme&utm_campaign=goop_readme)

Copyright (c) 2014 Irrational Industries, Inc. d.b.a. Nitrous.IO.<br>
This software is licensed under the [MIT License](http://github.com/nitrous-io/goop/raw/master/LICENSE).


goop

Build and manage your Go applications out of GOPATH.

# GOP

[简体中文](README_ZH.md)

[![CircleCI](https://circleci.com/gh/lunny/gop.svg?style=shield)](https://circleci.com/gh/lunny/gop)
[![codecov](https://codecov.io/gh/lunny/gop/branch/master/graph/badge.svg)](https://codecov.io/gh/lunny/gop)
[![](https://goreportcard.com/badge/github.com/lunny/gop)](https://goreportcard.com/report/github.com/lunny/gop) 

GOP is a project manangement tool for building your golang applications out of global GOPATH. In fact gop will keep both global GOPATH and every project GOPATH. But that means your project will  **not** go-getable. Of course, GOP itself is go-getable. GOP copy all denpendencies from global GOPATH to your project's `src/vendor` directory and all application's sources are also in `src` directory.

A normal process using gop is below:

```
git clone xxx@mydata.com:bac/aaa.git
cd aaa
gop ensure -g
gop build
gop test
```

## Features

* GOPATH compitable
* Multiple build targets support
* Put your projects out of global GOPATH

## Installation

Please ensure you have installed the `go` command, GOP will invoke it on building or testing

```
go get github.com/lunny/gop
```

## Directory structure

Every project should have a GOPATH directory structure and put a `gop.yml` int the root directory. This is an example project's directory tree.

```
<project root>
├── gop.yml
├── bin
├── doc
└── src
    ├── main
    │   └── main.go
    ├── models
    │   └── models.go
    ├── routes
    │   └── routes.go
    └── vendor
        └── github.com
            ├── go-xorm
            │   ├── builder
            │   ├── core
            │   └── xorm
            └── lunny
                ├── log
                └── tango
```

## Gop.yml

Gop will recognize a gop project which has `gop.yml`. The file is also a project configuration file. Below is an example. If you didn't define any target, the default target is src/main and the target name is the project name.

```yml
targets:
- name: myproject1
  dir: main
  assets:
  - templates
  - public
  - config.ini
  - key.pem
  - cert.pem
- name: myproject2
  dir: web
  assets:
  - templates
  - public
  - config.ini
  monitors:
  - config.ini
```

## Command

### init

Create the default directory structure tree.

```
mkdir newproject
cd newproject
gop init
```

and you can also create config file for vscode

```
gop init -e=vscode
```

### ensure

Automatically copy dependencies from $GOPATH to local project directory. `-g` will let you automatically call `go get <package>` when the package is missing on `GOPATH`. `-u` will always `go get <package>` on all the dependencies and copy them to `vendor`.

```
gop ensure [-g|-u] [target_name]
```

### status

List all dependencies of this project and show the status.

```
gop status [target_name]
```

### add

Add one or more packages to this project.

```
gop add <package1> <package2>
```

### update

Update one or more packages to this project. All missing dependent packages will also be added.
-f will update exists dependent packages.

```
gop update [-f] <package1> <package2>
```

### rm

Remove one or more packages from this project.

```
gop rm <package1> <package2>
```

### build

Run `go build` on the src directory. If you want to execute ensure before build, you can use `-e` flag.

```
gop build [-e] [target_name]
```

### run

Run `go run` on the src directory. `-w` will monitor the go source code changes and
automatically build and run again. `-e` will automatically execute `ensure` before every time build.

```
gop run [-w] [target_name]
```

### test

Run `go test` on the src directory. If you want to execute ensure before build, you can use `-e` flag.

```
gop test [-e] [target_name]
```

### release

Run `go release` on the src directory.

```
gop release [target_name]
```

## TODO

* [ ] Versions support, specify a dependency package verison
* [ ] Support run `gop` in `GOPATH`

plugin that provides way for auto-loading of Golang SDK, dependency management and start build environment in Maven project infrastructure.

![mvn-golang](assets/git_banner.png)

[![License Apache 2.0](https://img.shields.io/badge/license-Apache%20License%202.0-green.svg)](http://www.apache.org/licenses/LICENSE-2.0)
[![Java 8.0+](https://img.shields.io/badge/java-8.0%2b-green.svg)](http://www.oracle.com/technetwork/java/javase/downloads/index.html)
[![Maven central](https://maven-badges.herokuapp.com/maven-central/com.igormaznitsa/mvn-golang-wrapper/badge.svg)](http://search.maven.org/#artifactdetails|com.igormaznitsa|mvn-golang-wrapper|2.3.10|jar)
[![Maven 3.0.3+](https://img.shields.io/badge/maven-3.0.3%2b-green.svg)](https://maven.apache.org/)
[![PayPal donation](https://img.shields.io/badge/donation-PayPal-cyan.svg)](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=AHWJHJFBAWGL2)
[![YooMoney donation](https://img.shields.io/badge/donation-Yoo.money-blue.svg)](https://yoomoney.ru/to/41001158080699)

# Changelog

__2.3.10 (08-jun-2022)__

- updated dependencies
- default GoSDK version is 1.19

__2.3.9 (04-jul-2021)__

- fix for clean fail for multi-module project if some artifacts
  unresolvable [#90](https://github.com/raydac/mvn-golang/issues/90)
- fix for seldom error "Can't create temp folder" when building modules
  concurrently [#88](https://github.com/raydac/mvn-golang/issues/88)
- default GoSDK version is 1.16.5
- added autodetect for aarch64 [#87](https://github.com/raydac/mvn-golang/issues/87)

[full changelog](https://github.com/raydac/mvn-golang/blob/master/CHANGELOG.md)

# GO start!
__Taste Go in just two commands!__
```
mvn archetype:generate -B -DarchetypeGroupId=com.igormaznitsa -DarchetypeArtifactId=mvn-golang-hello -DarchetypeVersion=2.3.10 -DgroupId=com.go.test -DartifactId=gohello -Dversion=1.0-SNAPSHOT
mvn -f ./gohello/pom.xml package
```
The First command in th snippet above generates a maven project with some test files and the second command builds the project.
[Also you can take a look at the example `Hello world` project using the plugin](https://github.com/raydac/mvn-golang-example)

If you want to generate a multi-module project, then you can use such snippet
```
mvn archetype:generate -B -DarchetypeGroupId=com.igormaznitsa -DarchetypeArtifactId=mvn-golang-hello-multi -DarchetypeVersion=2.3.10 -DgroupId=com.go.test -DartifactId=gohello-multi -Dversion=1.0-SNAPSHOT
```

# Introduction
The Plug-in just wraps Golang tool-chain and allows to use strong maven based infrastructure to build Golang projects. It also can automatically download needed Golang SDK from the main server and tune needed version of packets for their branch, tag or revisions.
Because a Golang project in the case is formed as just maven project, it is possible to work with it in any Java IDE which supports Maven.
![mvn-golang-wrapper](https://raw.githubusercontent.com/raydac/mvn-golang/master/assets/doc_common.png)

# How it works
On start the plug-in makes below steps:
- analyzing the current platform to generate needed distributive name (it can be defined directly through properties)
- check that needed Golang SDK is already cached, if it is not cached then needed SDK will be loaded and unpacked from the main Golang SDK site
- execute needed go lang tool `bin/go` with defined command, the source folder will be set as current folder
- all folders of the project which are visible for maven (source folder, test folder, resource folders and test resource folders) are archived in ZIP file and the file is saved as a maven artifact into local maven repository (or remote maven repository). The generated ZIP artifact also contains information about dependencies which can be recognized by the plugin. In opposite to Java, Golang produces platform-dependent artifacts so that it doesn't make sense to share them through maven central but only resources and sources.  

# How to build
Because it is maven plugin, to build the plugin just use
```
mvn clean install -Pplugin
```
To save time, examples excluded from the main build process and activated through special profile
```
mvn clean install -Pexamples
```
# Important note about automatic Golang SDK load
If you have some problems with certificates during Golang SDK load, then just add `<disableSSLcheck>true</disableSSLcheck>` into plugin configuration to ignore check of certificates (also you can use property 'mvn.golang.disable.ssl.check'). Also it allows property `mvn.golang.disable.ssl.check` to disable SSL certificate check during network actions.

# How to add the plugin into maven project?
Below described build section for simple golang project which keeps source in `src` forlder and result should be placed into `bin` folder. Because it is golang project and mvn-golang plugin provides its own lifecycle, packaging for the project should be `<packaging>mvn-golang</packaging>`

```xml
<build>
    
    <sourceDirectory>${basedir}${file.separator}src</sourceDirectory>
    <directory>${basedir}${file.separator}bin</directory>

    <plugins>
      <plugin>
        <groupId>com.igormaznitsa</groupId>
        <artifactId>mvn-golang-wrapper</artifactId>
        <version>2.3.10</version>
        <extensions>true</extensions>
        <executions>
          <execution>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <packages>
                <package>main.go</package>
              </packages>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
</build>
```
# Work with dependencies

## Dependencies from Maven repository (since 2.3.0)

Plugin supports work with maven repository and can install and load dependencies from there. Artifacts generated by the plugin saved in maven respository as zip archives and `mvn-golang` must be used as `type`.
```xml
<dependency>
  <groupId>com.igormaznitsa</groupId>
  <artifactId>mvn-go-test-lib</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <type>mvn-golang</type>
</dependency>

```
Plugin makes some trick in work with Maven Golang dependencies, it downloads Golang artifacts from repository and unpack them into temporary folder, then all unpacked dependencies are added to `$GOPATH`. You can take a look at [example project which has two level dependency hierarchy](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-maven-repository).
Dependency mechanism is enabled by default for all goals which need it, but it can be off with `<scanDependencies>false</scanDependencies>`. If there is any conflicts or errors in Golang for Go modules then you can turn off Go modules with
```xml
<env>
  <GO111MODULE>off</GO111MODULE>
</env>
```
__Keep in mind that it is impossible use links to Github and Bitbucket libraries through `<dependencies>` maven mechanism, links to such dependencies should be processed by standard `GET` command and information about it you can find below.__

## Support of Module mode

Since 2.3.3 version, plug-in supports Golang module mode and allows to mix modules and work with golang maven dependencies, [I have made some sample to show the possibility](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-maven-module-mix). By default support of module mode is turned off, but it can be turned on through `<moduleMode>true</moduleMode>` or property `mvn.golang.module.mode`.

## Wrapped GET command

Plugin provides wrapper for Golang GET command and you can just define some external file contains package info through
system property `mvn.golang.get.packages.file`, the file will be loaded and parsed and its definitions will be added
into package dependencies. Format of the file is very easy. Each package described on a line in
format `package: <PACKAGE_NAME>[,branch: <BRANCH>][,tag: <TAG>][,revision: <REVISION>]` also it supports single line
comments through `//` and directive `#include <FILE_NAME>` to load packages from some external file. Also it supports
interpolation of properties defined in format `${property.name}` and provide access to maven, system and environment
variables.   
Example:

```
// example package file
#include "${basedir}/external/file.txt"
package:github.com/maruel/panicparse,tag:v1.0.2 // added because latest changes in panicparse is incompatible with termui
package:github.com/gizak/termui,branch:v2
```

This mechanism just makes work with dependencies easier and if you want to provide some specific flags and scripts to
process CVS folders you have to define configuration parameters in pom.xml, packages defined in the external file and in
the pom.xml will be mixed.

The Plug-in doesn't work with standard maven dependencies and they must be defined through task of the plugin, the
example of easiest case of dependencies is
```xml
<execution>
   <id>default-get</id>
   <configuration>
     <packages>
       <package>github.com/gizak/termui</package>
       <package>github.com/kataras/iris</package>
     </packages>
   </configuration>
</execution>
```
it will be executed as `bin/go get github.com/gizak/termui github.com/kataras/iris`

If you want work with specific branch then use below snipet
```xml
<execution>
  <id>default-get</id>
  <configuration>
    <buildFlags>
    <flag>-u</flag>
    </buildFlags>
    <packages>
      <package>github.com/gizak/termui</package>
    </packages>
    <branch>v2</branch>
  </configuration>
</execution>
```
if you want to have several dependencies with different tag and branch then take a look at the snipet below
```xml
<execution>
  <id>dependency1</id>
  <goals>
    <goal>get</goal>
  </goals>
  <configuration>
    <packages>
      <package>github.com/some/framework</package>
    </packages>
    <tag>1.0.1</tag>
  </configuration>
</execution>
<execution>
  <id>dependency2</id>
  <goals>
    <goal>get</goal>
  </goals>
  <configuration>
    <packages>
      <package>github.com/some/another</package>
    </packages>
    <branch>v2</branch>
  </configuration>
</execution>
```
sometime GIT can produce cache errors and in the case you can try to turn on auto-fix of such errors with `<autofixGitCache>true</autofixGitCache>` flag.   

# How to save generated artifact in repository?
By default, artifact will be installed into maven repository automatically during `install` phase if you want to turn off artifact installation then you can use standard maven properties
```xml
<properties>
    <maven.install.skip>true</maven.install.skip>
    <maven.deploy.skip>true</maven.deploy.skip>
</properties>
```
or disable plugin mojo execution
```xml
<execution>
  <id>default-mvninstall</id>
  <phase>none</phase>
</execution>
```

# Configuration

About configuration parameters, you can read at [the wiki page](https://github.com/raydac/mvn-golang/wiki/PluginConfigParameters).

# Testing
The Wrapper just wraps calls to Go tool and recognize the exit code, if call of `go test` is non-zero then build will be failed, it doesn't make any analysing of test reports!   
Sometime it is useful to use [GoConvey](https://github.com/smartystreets/goconvey) tool for testing, in the case use snippet below to add dependency and make testing verbose
```xml
<execution>
  <id>default-get</id>
  <configuration>
    <buildFlags>
      <flag>-u</flag>
    </buildFlags>
    <packages>
      <package>github.com/smartystreets/goconvey</package>
    </packages>
  </configuration>
</execution>
<execution>
  <id>default-test</id>
  <configuration>
    <buildFlags>
      <flag>-v</flag>
    </buildFlags>
  </configuration>
</execution>                    
```

# Some Examples
- __[Protobuf use example](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-protobuf)__
- __[Maven repository dependencies example](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-maven-repository)__
 - __[Maven repository dependencies together with modules example](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-maven-module-mix)__
 - __[Versioning of dependencies](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/test-git-cvs)__
 - __["Hello world!" console application.](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-helloworld)__
 - __[Console application with embedded text resource prepared with the `go-bindata` utility.](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-genbindata)__
 - __[Console application with `termui` library (it needs installation of some native libraries!).](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-termui)__
 - __[NES emulator.](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-nes)__
 - __[ANTLR usage.](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-antlr)__
 - __[Multimodule project.](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-multimodule)__
 - __[Preprocessing.](https://github.com/raydac/mvn-golang/tree/master/mvn-golang-examples/mvn-golang-example-preprocessing)__

The Best Go Libraries For Package Management - Unofficial libraries for package and dependency management. (7)

glide

godep

gom

goop

gop

mvn-golang

nut