After an uncertain history the
gb-vendor plugin has been replaced and returns to the main repository.
gb-vendor was a proof of concept for extending
gb with plugins.
gb-vendor was the second (the first was
gb-env, so that almost doesn’t count) plugin I wrote for
gb-vendor wrapped the
go tool, which made for a simple demo at GDG Berlin, but a confusing message – if
gb was a new build tool, why did it need the
go tool to fetch dependencies, etc.
Based on the feedback I received after the meetup, this issue became an acute point of confusion, so I moved
gb-vendor to its own repository to make it clear that it was not required for using
In the place of
gb-vendor I suggested that people follow the manual process set out in the getting started guide, or if their politics allowed, use git subtrees or submodules; the latter proving difficult to use if the dependency was itself a
The status quo has held, more or less, for a the last month, but it was clear that the majority of
gb users wanted an integrated solution that wouldn’t just allow them to set up an initial repository, but would assist them managing those dependencies as their project evolved.
Today, with the help of several contributors to the project (more on that in a bit) I landed a replacement version of
gb-vendor. We’re still working on the plugin’s documentation, but for the enthusiastic here is a quick overview.
% gb vendor Usage: gb vendor delete [flags] [package] - deletes a local dependency gb vendor fetch [flags] [package] - fetch a remote dependency gb vendor update [flags] [package] - updates a local dependency
gb-vendor fetch is our equivalent of
go get, it takes the usual import path that looks like a URL. Only GitHub is supported at the moment (but this is being actively improved). Vanity URLs are also not supported (yet). Here is an example
% gb vendor fetch github.com/kr/fs Cloning into '/tmp/gb-vendor-161722046'... remote: Counting objects: 18, done. remote: Total 18 (delta 0), reused 0 (delta 0), pack-reused 18 Unpacking objects: 100% (18/18), done. Checking connectivity... done. copyfile(dst: /home/dfc/devel/demo4/vendor/src/github.com/kr/fs/LICENSE, src: /tmp/gb-vendor-161722046/LICENSE) copyfile(dst: /home/dfc/devel/demo4/vendor/src/github.com/kr/fs/Readme, src: /tmp/gb-vendor-161722046/Readme) copyfile(dst: /home/dfc/devel/demo4/vendor/src/github.com/kr/fs/example_test.go, src: /tmp/gb-vendor-161722046/example_test.go) copyfile(dst: /home/dfc/devel/demo4/vendor/src/github.com/kr/fs/filesystem.go, src: /tmp/gb-vendor-161722046/filesystem.go) copyfile(dst: /home/dfc/devel/demo4/vendor/src/github.com/kr/fs/walk.go, src: /tmp/gb-vendor-161722046/walk.go) copyfile(dst: /home/dfc/devel/demo4/vendor/src/github.com/kr/fs/walk_test.go, src: /tmp/gb-vendor-161722046/walk_test.go)
This command fetches the source of
https://github.com/kr/fs and copies it into
.gitignore, and other dotfiles. The output is quite verbose at the moment, this will get more succinct over time.
gb-vendor fetching the same dependency twice is an error.
gb-vendor update updates an existing dependency to the head of its branch.
gb-vendor delete removes the source of the dependency from
$PROJECT/vendor/src/ and from the manifest file.
Hang on. Isn’t this the
gb project that made a big song and dance about not needing some kind of manifest or metadata file?
gb-vendor records dependencies fetched in a manifest file. This is a json file because encoding/json comes for free with the standard library, and is somewhat human readable. The manifest file is not used by
gb, it is used only by
The important part is
gb-vendor is optional.
gb does not require it, all
gb cares about is the projects’ source is laid out as expected – how it got there is not
gb’s concern. If your project wants to manage its dependencies another way,
gb doesn’t care.
And thank you to all the testers who have tried
gb and filed bug reports; you know who you are.