29

I'm using go modules as dependency management, and I'm having problem to install something like this:

go get -u github.com/go-critic/go-critic/...

the result from above was:

go: cannot find main module; see 'go help modules'
Luis.at.code
  • 299
  • 1
  • 3
  • 6
  • Did you init main module "go mod init "? For better understanding go to this stackoverflow question. https://stackoverflow.com/questions/52328952/how-to-use-a-module-that-is-outside-of-gopath-in-another-module – samadadi Nov 19 '18 at 10:56
  • sorry for the bad description, my problem is to install cli tools into my $GOPATH/bin directory. – Luis.at.code Nov 20 '18 at 05:06
  • See this related [answer](https://stackoverflow.com/a/57313319/11210494), which covers options for Go 1.11, the related functionality added in Go 1.12, and what hopefully will be supported in Go 1.14. – thepudds Aug 01 '19 at 19:30

7 Answers7

17

Edit: The original answer herein referred specifically to the state of the tooling in Go 1.11. Since the release of Go 1.12, this is no longer accurate. Please see this answer, and the ones it links to, for details of handling this situation in Go 1.12 and later.

If the GO111MODULE var is set to on, you have to be inside an initialized go module directory tree in order to use go get, even if you're trying to get a tool rather than a new dependency. This is a known and heavily debated issue:

https://github.com/golang/go/issues/27643

https://github.com/golang/go/issues/24250

https://github.com/golang/go/issues/25922

The solution, short term, is to run GO111MODULE=off go get <tool>. This explicitly disables the module support, even if you're in a module package currently, and forces it to only utilize your GOPATH.

Long-term, figuring out what the best solution is to support tool install via go get (or another command, like go install with a flag) is an ongoing area of discussion with little in the way of established consensus as of yet. However, there's a PR open for Go 1.12 that, if accepted, will allow go get to simply work while outside a module, even with GO111MODULE=on set.

Kaedys
  • 9,600
  • 1
  • 33
  • 40
  • 1
    https://github.com/golang/go/wiki/Modules#why-does-installing-a-tool-via-go-get-fail-with-error-cannot-find-main-module => GO111MODULE=on or GO111MODULE=auto – fuma Jan 31 '19 at 12:37
  • 1
    FWIW, this answer _was_ correct, but is no longer correct. See this [answer](https://stackoverflow.com/a/57317864/11210494) for more details and the answer as of Go 1.12, 1.13, and the likely new option in Go 1.14 for getting a tool without it updating your go.mod. Also, that answer covers what to do if you _want_ to explicitly track a tool as a versioned dependency in your go.mod (e.g., maybe because you want everyone to use the exact same version of a linter or code generator to avoid flapping due to slightly different versions of a tool in use by different people). – thepudds Aug 01 '19 at 22:53
17

Several of the other answers here have grown stale at this point.

There are at least two cases to consider:

Case 1

You want to install a tool, but you don't want to modify your current go.mod to track that tool as a dependency.

In short, with Go 1.12 or 1.13, the simplest solution is to cd to a directory without a go.mod, such as:

$ cd /tmp
$ go get github.com/some/tool@v1.0.1

Alternatively, gobin is a module-aware command to install or run binaries that provides additional flexibility, including the ability to install without altering your current module's go.mod

See this related answer for more details, including a solution for Go 1.11, as well as the likely new option in Go 1.14 for getting a tool without it updating your go.mod.

Case 2

On the other hand, if you want to explicitly track a tool as a versioned dependency in your go.mod, then see the "How can I track tool dependencies for a module?" FAQ on the modules wiki.

In short, you create a tools.go file in a separate package, and set a // +build tools build tag, such as:

// +build tools

package tools

import (
    _ "golang.org/x/tools/cmd/stringer"
)

The import statements allow the go command to precisely record the version information for your tools in your module's go.mod, while the // +build tools build constraint prevents your normal builds from actually importing your tools.

thepudds
  • 4,787
  • 3
  • 20
  • 37
  • 2
    I've just spent the day trying to untangle all the problems caused by the `tools.go` hack. I would suggest that people do not use it. See https://github.com/golang/go/issues/33926 – steinybot Nov 08 '19 at 00:18
  • For case 2, if I run `go mod download` on a freshly cloned project that has a `tools.go` file, do I then have to manually run `go install ` for each tool listed in the `tools.go` file or is there a single `go` command that installs all tools? – Sam Herrmann Jan 27 '21 at 03:06
  • @SamHerrmann, yes, you then manually run `go install ` A walkthrough in (Go By Example repo)[https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md] is a helpful example In the example of stringer, after setting of the tools.go file as shown above, you would run `> $ go install golang.org/x/tools/cmd/stringer` – Christopher Mott Jun 10 '22 at 21:58
7

I faced the same issue and resolved it by the below command.

$ go env -w GO111MODULE=auto

Nazmul Haque
  • 125
  • 1
  • 5
5

With Go 1.12 (February 2019), GO111MODULE=on go get will work.
(From issue 24250)

Modules

When GO111MODULE is set to on, the go command now supports module-aware operations outside of a module directory, provided that those operations do not need to resolve import paths relative to the current directory or explicitly edit the go.mod file.
Commands such as go get, go list, and go mod download behave as if in a module with initially-empty requirements.
In this mode, go env GOMOD reports the system's null device (/dev/null or NUL).

thepudds
  • 4,787
  • 3
  • 20
  • 37
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Try this command GO111MODULE=on go get -u github.com/go-critic/go-critic/...

KibGzr
  • 2,053
  • 14
  • 15
  • the magic doesnt work. i already export GO111MODULE=on. what i want is to install cli tools into my $GOPATH/bin directory with GO111MODULE=on. it made the go get tool behave different after turn on the GO111MODULE. – Luis.at.code Nov 20 '18 at 05:09
0

Just had the same issue on go1.11.2. Tried to set GO111MODULE=on, but this couldn't fix it.

My solution:

  1. Upgrade to use go 1.12.5: https://golang.org/doc/install?download=go1.12.5.linux-amd64.tar.gz

    This can resolve go: cannot find main module; see 'go help modules' issue.

  2. Then I got another issue go: cannot use path@version syntax in GOPATH mode,

    which can be resolved setting env GO111MODULE=on

Community
  • 1
  • 1
leo
  • 454
  • 5
  • 10
0

I had the same problem and it was "almost" solved directly. At first it did not work. This was because the module was already initialized and I had run the "go get..." command before I had set GO111MODULE=on.

To get it working I removed "go.mod" reinitialized the mod by running "go mod init ..." and re run the necessary "go get ...." commands.

D4v1dW3bb
  • 68
  • 6