README
¶
gvt, the go vendoring tool
gvt is a simple Go vendoring tool made for the GO15VENDOREXPERIMENT.
It's based entirely on gb-vendor.
You run gvt fetch when you would run go get. gvt downloads packages to ./vendor/.... With GO15VENDOREXPERIMENT=1 the compiler will find and use those dependencies without import path rewriting.
gvt works recursively as you would expect, and lets you update vendored dependencies. It also writes a manifest to ./vendor/manifest. Finally, it strips the VCS metadata so that you can commit the vendored source cleanly.
Packages whose dependencies are vendored with gvt are go build-able and go get-able by Go 1.5 with GO15VENDOREXPERIMENT=1 set.
Installation
go get -u github.com/FiloSottile/gvt
Usage
You know how to use go get? That's how you use gvt fetch.
$ gvt fetch github.com/fatih/color
2015/09/05 02:38:06 fetching recursive dependency github.com/mattn/go-isatty
2015/09/05 02:38:07 fetching recursive dependency github.com/shiena/ansicolor
$ tree -d
.
└── vendor
└── github.com
├── fatih
│ └── color
├── mattn
│ └── go-isatty
└── shiena
└── ansicolor
└── ansicolor
9 directories
$ cat > main.go
package main
import "github.com/fatih/color"
func main() {
color.Red("Hello, world!")
}
$ export GO15VENDOREXPERIMENT=1
$ go build .
$ ./hello
Hello, world!
$ git add main.go vendor/ && git commit
Full usage on GoDoc 
Alternative: not checking in vendored source
Some developers prefer not to check in the source of the vendored dependencies. In that case you can add lines like these to e.g. your .gitignore
vendor/**
!vendor/manifest
When you check out the source again, you can then run gvt rebuild to fetch all the dependencies at the revisions specified in the vendor/manifest file.
Please consider that this approach has the following consequences:
- the package consumer will need gvt to fetch the dependencies
- the dependencies will need to remain available from the source repositories: if the original repository goes down or rewrites history, build reproducibility is lost
go getwon't work on your package
Why
There are many Go vendoring tools, but they all have some subset of the following problems
- no GO15VENDOREXPERIMENT support: old tools are based on import path rewriting or GOPATH overrides
- requirement to run on clients: some require the user to install the tool and run it after cloning, which breaks
go get - no real fetching support: tools like Godep just copy packages from your GOPATH, instead of pulling it from the Internet
- prominent metadata files: there's no need for the manifest to be in your repository root, or in its own empty folder, or to be manually edited
- complex feature set: many are project management tools with included vendoring features
- different build stack: gb-vendor is awesome but it requires you to build your project with gb
Documentation
¶
Overview ¶
gvt, a simple go vendoring tool based on gb-vendor.
Usage:
gvt command [arguments]
The commands are:
fetch fetch a remote dependency rebuild rebuild dependencies from manifest update update a local dependency list list dependencies one per line delete delete a local dependency
Use "gvt help [command]" for more information about a command.
Fetch a remote dependency ¶
Usage:
gvt fetch [-branch branch | -revision rev | -tag tag] [-precaire] [-no-recurse] importpath
fetch vendors an upstream import path.
The import path may include a url scheme. This may be useful when fetching dependencies from private repositories that cannot be probed.
Flags:
-branch branch fetch from the name branch. If not supplied the default upstream branch will be used. -no-recurse do not fetch recursively. -tag tag fetch the specified tag. If not supplied the default upstream branch will be used. -revision rev fetch the specific revision from the branch (if supplied). If no revision supplied, the latest available will be supplied. -precaire allow the use of insecure protocols.
Rebuild dependencies from manifest ¶
Usage:
gvt rebuild
rebuild fetches the dependencies listed in the manifest.
It's meant for workflows that don't include checking in to VCS the vendored source, for example if .gitignore includes lines like
vendor/** !vendor/manifest
Note that such a setup requires "gvt rebuild" to build the source, relies on the availability of the dependencies repositories and breaks "go get".
Flags:
-precaire allow the use of insecure protocols.
Update a local dependency ¶
Usage:
gvt update [-all] import
update will replaces the source with the latest available from the head of the master branch.
Updating from one copy of a dependency to another comes with several restrictions. The first is you can only update to the head of the branch your dependency was vendored from, switching branches is not supported. The second restriction is if you have used -tag or -revision while vendoring a dependency, your dependency is "headless" (to borrow a term from git) and cannot be updated.
To update across branches, or from one tag/revision to another, you must first use delete to remove the dependency, then fetch [-tag | -revision | -branch ] [-precaire] to replace it.
Flags:
-all will update all dependencies in the manifest, otherwise only the dependency supplied. -precaire allow the use of insecure protocols.
List dependencies one per line ¶
Usage:
gvt list [-f format]
list formats the contents of the manifest file.
Flags:
-f
controls the template used for printing each manifest entry. If not supplied
the default value is "{{.Importpath}}\t{{.Repository}}{{.Path}}\t{{.Branch}}\t{{.Revision}}"
Delete a local dependency ¶
Usage:
gvt delete [-all] importpath
delete removes a dependency from the vendor directory and the manifest
Flags:
-all remove all dependencies
Source Files
Directories