go: cmd/go: go mod init fails to determine module path in subdirectory

Have you tried go mod init <module_name>? (e.g. go mod init goelster)

Being new to go mod, I run into the exact same issue today. It did take me a while googling, with the right combination of key words to finally land in here. The documentation makes sense to me and I’m OK with the implicit dependency of go mod and git. However, I’d suggest (at least) make the error message more meaningful or explicit. It will save quite a bit of time for n00bs. Cheers,

I have been able to resolve this with code in a repo subdir with

go mod init `pwd` 

Surely this can be automated?!

go mod init with no arguments does it’s best to determine a module path if the current directory belongs to a VCS repository that has a remote:

$ cd $(mktemp -d)
$ git init
Initialized empty Git repository in /tmp/tmp.T8elQyoqel/.git/
$ git remote add origin https://github.com/myitcv/gobin
$ go mod init
go: creating new go.mod: module github.com/myitcv/gobin

You can alternatively provide an explicit argument, as you outlined in https://github.com/golang/go/issues/27951#issuecomment-429533293.

The bug you correctly identified is that go mod init with no arguments does not do the correct thing in a subdirectory of the VCS repo root:

$ mkdir inner
$ cd inner
$ go mod init
go: cannot determine module path for source directory /tmp/tmp.T8elQyoqel/inner (outside GOPATH, no import comments)

This has bitten me for the second time today. Needs a meaningful error message at the very least

I have been able to resolve this with code in a repo subdir with

go mod init `pwd` 

This solved it for me! Thank you @joshuamkite!!

That creates a go.mod:

❯ go mod init goelster
go: creating new go.mod: module goelster

❯ cat go.mod
module goelster

is this the expected behavior?

It’s good enough for people who already know the idiosyncrasy, not good enough for n00bs like me coming from dep. There will be lots of n00bs.

It seems to me that go mod init is completely dependent on the existence of a git remote named “origin”. I got the OP’s output here because I only had the origins “upstream” and “rfay”. Once I added an “origin” (equivalent to upstream), then go mod init worked. This doesn’t seem like the behavior I’d expect.

maybe a hint towards the correct command?

cannot guess module path for source directory ...
try specifying module path explicitly: 

    go mod init <PATH>

I’d 👍 for expanding go help mod init as an alternative.

Killing the github.com special case seems fine. I would like to leave all the other, better, higher-priority auto-deriving of module paths, since those are much more accurate and helpful.

The remote name “origin” is absolutely arbitrary (although ever-so-widely used), and should not be a fundamental assumption. Just a --remote=<something> arg would solve the problem and make it explicit that go mod init is dependent on the remote (and on a specific named remote). It would be fine for “origin” to be the default.