Global tool/dependency managing with gobin
#90
Labels
Milestone
Comments
arcticicestudio
added a commit
that referenced
this issue
Oct 16, 2019
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
arcticicestudio
added a commit
that referenced
this issue
Oct 17, 2019
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. Also see gobin's FAQ page in the repository wiki [6] for more details. 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 [6]: https://github.com/myitcv/gobin/wiki/FAQ Relates to GH-82 Relates to GH-88 Resolves GH-90
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #82 and #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
$GOMODenvironment 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 (golang/go#25922, golang/go#27653).
The official Go GitHub repository wiki provides a section on “How can I track tool dependencies for a module?” that describes a workaround that tracks tool dependencies through the Go module logic via a
tools.gofile with a dedicatedtoolsbuild 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
mainpackage can not be imported in such a file.In order to tackle this problem, a user from the community implemented gobin, 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()). 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/$GOBINby using a cache directory instead. This keeps the system clean and ensures the correct version of a module executable is already used.gobinis 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.Also see gobin's FAQ page in the repository wiki for more details.
To finally manage the tool dependency problem for snowsaw,
gobinwill be integrated into the Mage build toolchain.The text was updated successfully, but these errors were encountered: