Alternative Vendoring Strategy

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
• ?