Automatically fetch your project ' s dependencies with GB

This is a creation in Article, where the information may have evolved or changed.

GB has been-development for just-a year now. Since The announcement in could the project have received over 1,600 stars, produced releases, and attracted all contr Ibutors.

Thanks to a committed band of early adopters, GB have grown to is a usable day to day replacement for the Go tool. But, there are one area where GB have not lived up to my hopes, and which is dependency management.

GB ' s $PROJECT/vendor/ directory is the inspiration for the Go tool ' s vendor/ directory (alth Ough their implementations differ greatly) and have delivered on their goal of reproducible builds for Go Projects. howe Ver, the success of GB ' s project based model, and vendoring code in general, Has a few problems. Specifically, wholesale copying (or forking if you prefer) of one code base into another continues to sidestep the ISSUE&N Bsp;of adoption of a proper release and versioning culture amongst Go developers.

To being fair, for Go developers using the tools they has access to today–including Gb–there are no incentive to release thei R code. As a Go package author, you get no points for doing proper versioned releases if your build tool just pulls from any HEAD The. There is similarly limited value in adopting a version numbering policy like SemVer if your tools only memorise the Git re Vision copied your code at.

A second problem, equally poorly served by GB or the " vendor/ the" Go tool, is developers and projects who cannot, Usually for legal reasons, or does not wish to, copy code wholesale into their project. Suggestions of using Git submodules has been soundly dismissed as unworkable.

With the release of GB 0.4.3, there is a new-to-manage dependencies with GB. This new method does not replace GB vendor or as the $PROJECT/vendor recommended method for achieving reproducible builds, but it does Es acknowledge that vendoring are not appropriate for all use cases.

To is clear, this new mode of managing dependencies does not supersede or deprecate the existing mechanisms of cloning SOU Rce code into $PROJECT/vendor . The automatic download feature is optional and was activated by the project author creating a file in their project ' s root Called, $PROJECT/depfile .

If you had a GB project that is currently vendoring code, or you ' re using GB vendor restore to actively avoid cloning cod E into your project, your can try this feature today, with the following caveats:

1. Currently only GitHub is supported. This was because the new facility uses the GitHub API to download release tarballs via HTTPS. Vanity URLs that redirect to GitHub is also not supported yet, but would be supported soon.
2. The repository must has made a release of its code, and that release must is tagged with a tag containing a valid SemVer 2.0.0 version number. The format of the tag is described in this proposal. If a dependency you want the consume in your GB project have not released their code and then the ask them to does so.

Polishing this feature'll be the remainder of the 0.4.x development series. After the this is the complete GB vendor would be getting some attention. Ultimately both GB vendor and do the $PROJECT/depfile same thing–one copies the source of your dependencies into your project, the OT She into your home directory.