Skip to content

Instantly share code, notes, and snippets.

@gabriel

gabriel/vendor.md

Last active June 23, 2016 19:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gabriel/0506a1276b6e6c03fc6cec5d7db1afb1 to your computer and use it in GitHub Desktop.
Save gabriel/0506a1276b6e6c03fc6cec5d7db1afb1 to your computer and use it in GitHub Desktop.
Download ZIP
Alternative Vendoring Strategy
Raw
vendor.md

Vendoring Somewhere Else?

Instead of vendoring inside client and kbfs (and including client in kbfs), we vendor at github.com/keybase/vendor (as a repo).

When a user wants to build:

  • go get github.com/keybase/client/go
  • go get github.com/keybase/kbfs
  • go get github.com/keybase/vendor (if they want to use vendoring)

An example vendoring repo that works right now is at: https://github.com/keybase/go-vendor-test

Mobile

For some background, on mobile, we need to build client+kbfs in a single library (for gomobile bind, to have KBFS support). We use a script for that: https://github.com/keybase/client/pull/3179/files#diff-ed391117ec577242383c3e80e1d65bbc

It does the following:

  • Creates a tmp GOPATH
  • Copies client/go into GOPATH
  • Copies kbfs into GOPATH
  • Combines the vendoring from both repos into github.com/keybase/vendor

This strategy would obviate the need for that.

Git Submodules

No.

Pros

  • We need both repos to have compatible vendor for mobile builds, this ensures that
  • Using single versions of 3rd party libraries for our main go repos
  • Not vendoring client inside kbfs
  • Vendoring is not in each repo, so it is optional
  • Simulates a mono-repo approach (sort of), without forcing one repo
  • ?

Cons

  • Updating a dependency requires making sure it works across our main go repos
  • Not atomic
  • Extra step to go get vendoring
  • Maybe we should be mono-repo-ing instead
  • ?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment