Yes, that is the standard Go approach and the only real option at the moment.
That said, I'm not really a fan of the vendoring approach because it means that all of the dependencies have to be copied directly into the repository under a _workspace directory and all the import paths then have to be modified accordingly even though they are already in a separate repository under the organization. It also means updates to dependencies end up cluttering up the commit history of the main repository instead of being isolated to the core network/daemon development.
Eventually, I would like to see a btcd specific build tool that makes use of revision pinning (we already keep a
deps.txt in the repository that has the revisions of all of the deps at each release) in order to obtain the specific revisions,
validates the commit signatures, and then uses
gb to do the deterministic build.
In my experience, most people don't actually ensure the signatures match, so I think having that happen as a part of the installation for releases (only release commits are signed) would be a big win.
I'm spitballing here, but it could look something like this:
Code:
$ btcdbuild <latestrelease / [version] / master>
Updating dependencies...Done
Checking signatures...Valid/INVALID (stop if invalid)
Building...Done
Not specifying an argument would build the latest release and be equivalent to specifying 'latestrelease'. Otherwise a specific version could be specified or 'master' for the bleeding edge.
