3 ms·
If you don't like GOPATH workspace and use a separate GOPATH for each project, you should just use gb [1] which was designed and built with that use case as a g
by shurcooL 11y ago
If you don't like GOPATH workspace and use a separate GOPATH for each project, you should just use gb [1] which was designed and built with that use case as a goal.
Build tool and language are somewhat separate concepts.
[1] https://getgb.io https://getgb.io
- lobster_johnson 11y agogb is promising, but doesn't feel like the complete solution quite yet. The author only hesitantly added support for managing dependencies, which is done through a separate "plugin", gb-vendor. It maintains an internal manifest file which only the gb-vendor tool is supposed to manage. It's not like NPM or Ruby's Bundler where you the manifest file (package.json, Gemfile) is what you edit to produce the vendor tree. Support for branches and tags seems to missing, as does any notion of versioning, so of course semver is not on the table. I understand the Unix philosophy of keeping dependency management and building separate tools, but I suspect that what most Go developers want is a fully integrated solution. I know I do.