FAQ

This FAQ is work-in-progress.

What does 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 gobin you:

• get some of the behaviour of go get, go install and go run combined
• can have multiple versions of a tool available
• have the equivalent of go get whilst 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 gobin?

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:

golang/go/issues/#24250:

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 GO111MODULE=on):

1. requires that you run the go command in the context of a go.mod
2. modifies the go.mod with the results of the go get (see module-aware go get help for more information)

This second point is picked up in golang/go/issues/#27643.

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 go.mod?
• should main-module installed tools share the same go.mod as 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:

gobin github.com/myitcv/gobin

What is the goal for gobin?

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 gobin proves incorrect, unworkable etc
• it lives on as a separate tool outside of the Go distribution
• parts of gobin are absorbed into the go tool
• a variant of gobin is vendored and distributed alongside the go tool, much like godoc was in in Go 1.11 and earlier
• ...