Building on the ideas started in #44.

Currently, the -m flag tells gobin to use the main module for resolution of dependencies. -m can also, therefore, be thought of as "non-global" mode. In -m mode, we use the guidance at golang/go#25922 (comment) for keeping track of the tools we require in a build-ignored tools.go file.

Under this behaviour however, -m mode ends up cluttering our main module.

#44 proposed an alternative means of capturing the list of tools we require in a go.tools file. This issue more precisely specifies the behaviour as follows:

go.tools will capture the import paths of tools we require, e.g.:

# go.tools
golang.org/x/tools/cmd/stringer
example.com/blah/v2

gobin will then use synthetic nested modules (in a .gobin directory) per main package for module resolution (including the main package's module). For example:

// $PWD/.gobin/golang.org/x/tools/cmd/stringer/go.mod
module mod

require (
    golang.org/x/tools v0.0.0-20190826060629-95c3470cfb70
)

Points to note:

• The filepath of nested modules will need to use the same escaping as seen in the cmd/go module cache
• All non-directory replace directives in the main package's main module will appear in the synthetic nested module for a main package

cc @rogpeppe @mvdan