Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: "go: cannot find main module; see 'go help modules'" #31997

Closed
s681562 opened this issue May 13, 2019 · 15 comments
Closed

question: "go: cannot find main module; see 'go help modules'" #31997

s681562 opened this issue May 13, 2019 · 15 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@s681562
Copy link

s681562 commented May 13, 2019

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

creating a file hello.go in /home/ubuntu/go/src/hello/

package main

import "fmt"

func main() {
fmt.Printf("hello, world\n")
}

What did you expect to see?

go into /home/ubuntu/go/src/hello/
call go build
now i expected an created file hello (in go on windows it was hello.exe)

What did you see instead?

go: cannot find main module; see 'go help modules'

Does this issue reproduce with the latest release (go1.12.5)?

every time (but only under ubuntu@DESKTOP windows sub system. After installing go on windows directly, all was working fine. I was able to call go build and an hello.exe was created. After calling hello.exe an hello was printed out on cmd. But now under ubunto on wsl i can call go version, go get, go list... but go build throw this "go: cannot find main module; see 'go help modules'" error. I try to delete export GO111MODULE=on in .profile, but this issue is still here.

System details

go version go1.12.2 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ubuntu/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ubuntu/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOROOT/bin/go version: go version go1.12.2 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.12.2
uname -sr: Linux 4.4.0-17763-Microsoft
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27.
@andybons andybons changed the title go build : "go: cannot find main module; see 'go help modules'" question: "go: cannot find main module; see 'go help modules'" May 13, 2019
@andybons andybons added this to the Unreleased milestone May 13, 2019
@andybons
Copy link
Member

@jayconrod @bcmills

@bcmills
Copy link
Contributor

bcmills commented May 13, 2019

I try to delete export GO111MODULE=on in .profile, but this issue is still here.

You probably still have GO111MODULE=on set in your environment. If you're using a sh-like shell, unset GO111MODULE or export GO111MODULE=auto should put things back into auto mode.

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label May 13, 2019
@gopherbot
Copy link
Contributor

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@marcelotoledo
Copy link

I am having the exact same problem. Have unset the environment variable. Also tried with auto, nothing changes. We have monorepo here, so it's only one go.mod in the root for the entire project. I imagine this is causing the confusion? Any ideas on how to debug this?

@agnivade
Copy link
Contributor

Hello @marcelotoledo, unlike other projects, we do not use the issue tracker for questions such as these. It is only used for bugs and feature proposals. Please feel free to ask it in any of these forums below:

Thanks

@D4v1dW3bb
Copy link

Unsupported

Open a directory that contains a module in a subdirectory. gopls will not work in this case.

For vscode I have a workaround, do not know if this work for other editors.

My directory structure is:

Projects
  Someproject1
    microservice1
      go.mod
      go.sum
      main.go
    microservice2
      go.mod
      go.sum
      main.go
  Someproject2
  ...

opening "Somepoject1" in vscode causes a problem.
To solve this I have made a second directory structure:

Workspaces
  Someproject1
  Someproject2

If i start working on a project I open the respective directory in "Workspace"s in vscode. There I add al the microservice directories from the corresponding project directory in "Projects" to the workspace.

it's a little bit of work to setup but it works.

no errors any more

@dwibudut
Copy link

dwibudut commented Feb 21, 2021

After upgrade to go1.16, try to set :

go env -w GO111MODULE=auto

https://blog.golang.org/go116-module-changes

Thx

@bhargodevarya
Copy link

@dwbuiten It worked on my machine, thank you.

@drewkiimon
Copy link

After upgrade to go1.16, try to set :

go env -w GO111MODULE=auto

https://blog.golang.org/go116-module-changes

Thx

You're the GOAT

@abheyogy
Copy link

abheyogy commented Mar 2, 2021

After upgrade to go1.16, try to set :

go env -w GO111MODULE=auto

https://blog.golang.org/go116-module-changes

Thx

Works for me, was missing this & getting the same error with go koans.

@jayconrod
Copy link
Contributor

This issue is closed, but it looks like a lot of people are seeing similar error messages since module-aware mode is now enabled by default in Go 1.16 (#41330).

I've opened #44745 to clarify the error messages. That should explain the problem and suggest a solution when possible. I'd like to backport that to the next 1.16 patch release.

Note that go env -w GO111MODULE=auto probably won't work in Go 1.17. We plan to drop support for GOPATH builds and that environment variable.

drfloob added a commit to drfloob/grpc that referenced this issue Mar 12, 2021
Go v1.16 introduced module-aware commands by default. This version
upgrade broke our http2 interop tests (see grpc#25660). Setting the go
environment variable `GO111MODULE` to "auto" makes go tools behave as
they did before the v1.16 change.

Docs on the flag: https://golang.org/ref/mod#mod-commands
Recent discussion on golang/go:
  golang/go#31997 (comment)
drfloob added a commit to grpc/grpc that referenced this issue Mar 15, 2021
…de to go v1.16 (#25707)

Go v1.16 introduced module-aware commands by default. This version
upgrade broke our http2 interop tests (see #25660). Setting the go
environment variable `GO111MODULE` to "auto" makes go tools behave as
they did before the v1.16 change, but will not be compatible with v1.17.
This PR introduces a minimal go.mod file for the interop test to appease go
v1.16.

Docs on the flag: https://golang.org/ref/mod#mod-commands
Recent discussion on golang/go:
  golang/go#31997 (comment)
@rsotar
Copy link

rsotar commented Apr 6, 2021

After upgrade to go1.16, try to set :

go env -w GO111MODULE=auto

https://blog.golang.org/go116-module-changes

Thx

work for me thanks !!!

@ReeganExE
Copy link

I got go: cannot find main module; see 'go help modules' when trying to debug a main.go in VSCode.
So init a go module works for me go init <module-name>

@aaf1097
Copy link

aaf1097 commented Sep 4, 2021

After upgrade to go1.16, try to set :

go env -w GO111MODULE=auto

https://blog.golang.org/go116-module-changes

Thx

Thank a lot!!

@Jeklah
Copy link

Jeklah commented Nov 5, 2021

After upgrade to go1.16, try to set :

go env -w GO111MODULE=auto

https://blog.golang.org/go116-module-changes

Thx

Thanks for this, this worked for me.

@golang golang locked and limited conversation to collaborators Nov 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests