Global tool/dependency managing with gobin
#91
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In GH-82 and GH-88, two workarounds have been implemented in order to prevent the "pollution" of the project Go module file due to development tools and dependencies when installed through `go get`. The workaround to install modules/packages outside of the project root directory (preventing the Go toolchain to pick up the `$GOMOD` environment variable initialized with the path to the projects Go module file) works, but might result in problems due to already installed executables with different versions. The general problem of tool dependencies a a long-time known issue/weak point of the current Go toolchain and is a highly rated change request from the Go community [1,2]. The official Go GitHub repository wiki provides a section on "How can I track tool dependencies for a module?" [3] that describes a workaround that tracks tool dependencies through the Go module logic via a `tools.go` file with a dedicated `tools` build tag to prevent these modules to be included in production binary artifact builds. This approach works fine for non-main packages, but for CLI tools that are only implemented in the `main` package can not be imported in such a file. In order to tackle this problem, a user from the community implemented `gobin` [4], "an experimental, module-aware command to install/run main packages". It allows to install or run main-package commands without "polluting" the Go module file by default. It downloads modules in version-aware mode into a binary cache path within the system's cache directory (`os.UserCacheDir()` [5]). It can be used to query for the path of the executable for a given module/package to simplify the usage from within Mage. It prevents problems due to already installed global binaries in `$GOPATH`/`$GOBIN` by using a cache directory instead. This keeps the system clean and ensures the correct version of a module executable is already used. `gobin` is still in an early development state, but has already received a lot of positive feedback and is used in many projects. There are also many members of the core Go team that are contributing to the project and the chance is high that it will influence the official future Go toolchain implementation or might be partially ported. To finally manage the tool dependency problem for snowsaw, `gobin` has been integrated into the Mage build toolchain. [1]: golang/go#25922 [2]: golang/go#27653 [3]: https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module [4]: https://github.com/myitcv/gobin [5]: https://golang.org/pkg/os/#UserCacheDir Relates to GH-82 Relates to GH-88 GH-90
arcticicestudio
changed the title
gobingobin
svengreb
approved these changes
Oct 17, 2019
arcticicestudio
deleted the
improvement/gh-90-global-tool-management-gobin
branch
This was referenced Oct 17, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #90