A new gb-vendor plugin

After an uncertain history the gb-vendor plugin has been replaced and returns to the main repository.

History

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.

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 gb.

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 gb project.

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.

gb-vendor is back

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.

Usage

% 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 $PROJECT/vendor/src/github.com/kr/fs, excluding .git, .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.

Manifest, what!

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 gb-vendor.

gb-vendor is optional

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.

Thank you valued associates

gb would not be possible without its contributors. I want to give special thanks to Mario Kostelac, Dávid Kaya, and Jesus Alvarez.

And thank you to all the testers who have tried gb and filed bug reports; you know who you are.

Previous: