Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
This FAQ is work-in-progress.
gobin give me that the
go tool doesn't?
Currently, if you use the
go tool to install a top level command, and you want to respect that command's module dependencies, you must be inside an existing Go module. By contrast,
gobin will build using module information from the top level command being installed (if available), so you can get builds with deterministically reproducible dependencies without needing to create a module. Replace and exclude clauses in the command's
go.mod file will also be respected.
Compared to the Go 1.11 series, with
- get some of the behaviour of
- can have multiple versions of a tool available
- have the equivalent of
go getwhilst in module-aware mode but this does not modify your
go.mod; indeed you can choose whether you want to run in global mode (the default) or main-module mode for the install/run operation
- can run a main package without the overhead of the linking phase
Why have you created
Module support in the Go 1.11 series is experimental. There are a number of questions that were intentionally left unanswered in this release series, a number of bugs that surfaced, and a number of gaps that became obvious as people started to use modules more heavily.
gobin is an experiment to try to understand potential answers to these questions/issues/gaps.
Looking at the main issues around these points:
This is a feature request to be able to install a program/main package to a user's home directory (basically $GOBIN) outside of a module context.
The main issue being that when running
go get in module-aware mode (i.e. you are outside
GOPATH or have
- requires that you run the
gocommand in the context of a
- modifies the
go.modwith the results of the
go get(see module-aware
go gethelp for more information)
This second point is picked up in
golang/go/issues/#27653 picks up the point that a module's tool dependencies might well be at different (major) versions to those being used globally. So we need some means to avoid the "race" condition of programs with the same name but different (major) version number being installed to the same directory.
golang/go/issues/#25416 concludes that
go run intentionally re-runs the link step and does not cache the resulting binary, which means
go run X is going to be (much) slower than simply running an installed binary.
golang/go/issues/#25922 seeks clarification on the best way to add/structure tools as dependencies to a module.
In the course of discussing these various issues a number of other points/questions have come up:
- do all globally-installed tools share the same
go.mod? i.e. are they installed effecitvely into the same "GOPATH" where they share dependencies, or is each tool installed using exactly the dependencies defined via it's respective
- should main-module installed tools share the same
go.modas the non-tool dependencies in the main-module?
Hang on, isn't
gobin a tool too? Catch-22?
Yes, it is a tool. And just like the
go tool can compile itself,
gobin can install itself. But, like the
go tool, we need to bootstrap the process by installing
gobin "by hand" (see the README). Then you can do things like:
What is the goal for
gobin is an experiment, as such there are no expectations over its future.
There are a number of potential outcomes, not limited to the following list:
- it dies; the hypothesis being tested by
gobinproves incorrect, unworkable etc
- it lives on as a separate tool outside of the Go distribution
- parts of
gobinare absorbed into the
- a variant of
gobinis vendored and distributed alongside the
gotool, much like
godocwas in in Go 1.11 and earlier