Package Management for Golang
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
vendordirectory within a Go package. This feature, first introduced in Go 1.5, allows each package to have a
vendordirectory containing dependent packages for the project. These vendor packages can be installed by a tool (e.g. glide), similar to
go getor they can be vendored and distributed with the package.
The Go community is now using Go Modules to handle dependencies. Please consider using that instead of Glide. Glide is now mostly unmaintained.
github.com/Masterminds/semverpackage can parse can be used.
gotools
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.yamlfile 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.yamlfile 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
gotools can find and use them. A
glide.lockfile is generated containing all the dependencies, including transitive ones.
The
glide initcommand can be use to setup a new project,
glide updateregenerates the dependency versions using scanning and rules, and
glide installwill install the versions listed in the
glide.lockfile, skipping scanning, unless the
glide.lockfile 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 to see this philosophy in action.
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:
$ 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 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:
$GOPATH/src/github.com/Masterminds/glideand change directory into it
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.
make build
This will leave you with
./glide, which you can put in your
$PATHif you'd like. (You can also take a look at
make installto install for you.)
The Glide repo has now been configured to use glide to manage itself, too.
$ 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.yamlin this directory, or examples in the
docs/directory.
Initialize a new workspace. Among other things, this creates a
glide.yamlfile 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.
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.
You can download one or more packages to your
vendordirectory and have it added to your
glide.yamlfile with
glide get.
$ glide get github.com/Masterminds/cookoo
When
glide getis used it will introspect the listed package to resolve its dependencies including using Godep, GPM, Gom, and GB config files.
Download or update all of the libraries listed in the
glide.yamlfile and put them in the
vendordirectory. 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.lockfile will be created or updated with the dependencies pinned to specific versions. For example, if in the
glide.yamlfile a version was specified as a range (e.g.,
^1.2.3) it will be set to a specific commit id in the
glide.lockfile. That allows for reproducible installs (see
glide install).
To remove any nested
vendor/directories from fetched packages see the
-vflag.
When you want to install the specific versions from the
glide.lockfile use
glide install.
$ glide install
This will read the
glide.lockfile and install the commit id specific versions there.
When the
glide.lockfile doesn't tie to the
glide.yamlfile, such as there being a change, it will provide a warning. Running
glide upwill recreate the
glide.lockfile when updating the dependency tree.
If no
glide.lockfile is present
glide installwill perform an
updateand generate a lock file.
To remove any nested
vendor/directories from fetched packages see the
-vflag.
When you run commands like
go test ./...it will iterate over all the subdirectories including the
vendordirectory. 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
novendorcommand comes in. It lists all of the directories except
vendor.
$ go test $(glide novendor)
This will run
go testover all directories of your project except the
vendordirectory.
When you're scripting with Glide there are occasions where you need to know the name of the package you're working on.
glide namereturns the name of the package listed in the
glide.yamlfile.
Glide includes a few commands that inspect code and give you details about what is imported.
glide treeis 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 treealso prints the location of the package being imported.
This command is deprecated and will be removed in the near future.
Glide's
listcommand 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
Print the glide help.
$ glide help
Print the version and exit.
$ glide --version glide version 0.12.0
For full details on the
glide.yamlfiles see the documentation.
The
glide.yamlfile does two critical things:
A brief
glide.yamlfile looks like this:
package: github.com/Masterminds/glide import: - package: github.com/Masterminds/semver - package: github.com/Masterminds/cookoo version: ^1.2.0 repo: [email protected]:Masterminds/cookoo.git
The above tells
glidethat...
github.com/Masterminds/glide
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/cookooin the
vendordirectory. (Note that
packageand
repocan 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/semverpackage. 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-gypsyand not
github.com/kylelemons/go-gypsy/yaml.
The Git, SVN, Mercurial (Hg), and Bzr source control systems are supported. This happens through the vcs package.
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.
These are works in progress, and may need some additional tuning. Please take a look at the vcs package. If you see a better way to handle it please let us know.
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).
There are two parts to importing.
glide importcommand. For example, you can run
glide import godepfor Glide to detect the projects Godep configuration and generate a
glide.yamlfile for you.
Each of these will merge your existing
glide.yamlfile 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
A: Yes. Using the
osand
archfields 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:
- package: some/package os: - darwin arch: - amd64
The package will not be fetched for other architectures or OSes.
This package is made available under an MIT-style license. See LICENSE.txt.
We owe a huge debt of gratitude to the GPM and GVP projects, which inspired many of the features of this package. If
glideisn'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.
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.