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

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

Open
andig opened this Issue Oct 1, 2018 · 12 comments

Comments

Projects
None yet
5 participants
@andig

andig commented Oct 1, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.11

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

❯ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/goelster/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/73/89ycv7qn51j4kbm04jsz9b840000gn/T/go-build453007721=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Trying to init go modules, I'm seing it fail from one folder but working from another. Both folders only contain two simple go files:

~/htdocs/canprogs/go master*
❯ go mod init
go: cannot determine module path for source directory /Users/andig/htdocs/canprogs/go (outside GOPATH, no import comments)

~/htdocs/goelster master
❯ go mod init
go: creating new go.mod: module github.com/andig/goelster

❯ ls
elster.go main.go
@bcmills

This comment has been minimized.

Member

bcmills commented Oct 1, 2018

Please attach the output of go env (as requested by the issue template).

@bcmills

This comment has been minimized.

Member

bcmills commented Oct 1, 2018

Which directory (if any) is at the root of your VCS checkout, and what is your GOPATH?

@bcmills bcmills added this to the Go1.12 milestone Oct 1, 2018

@bcmills bcmills changed the title from go mod init fails to cmd/go: go mod init fails in subdirectory Oct 1, 2018

@bcmills bcmills changed the title from cmd/go: go mod init fails in subdirectory to cmd/go: go mod init fails to determine module path in subdirectory Oct 1, 2018

@andig

This comment has been minimized.

andig commented Oct 1, 2018

Please attach the output of go env

Sorry, only noticed the "operating system" question, added go env above. ~/htdocs/canprogs is a git root, so is ~/htdocs/goelster. Neither is part of the gopath.

@andig

This comment has been minimized.

andig commented Oct 4, 2018

@bcmills I see this has been scheduled- seems I've hit an actual issue here?

@xswordsx

This comment has been minimized.

xswordsx commented Oct 10, 2018

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

@andig

This comment has been minimized.

andig commented Oct 13, 2018

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?

@myitcv

This comment has been minimized.

Member

myitcv commented Nov 13, 2018

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 #27951 (comment).

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)

@bcmills bcmills modified the milestones: Go1.12, Go1.13 Nov 14, 2018

@rfay

This comment has been minimized.

rfay commented Nov 24, 2018

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.

@myitcv

This comment has been minimized.

Member

myitcv commented Nov 24, 2018

This doesn't seem like the behavior I'd expect.

@rfay - what behaviour would you expect if there are multiple remotes?

Having go mod init specifically look for a remote called origin seems like a reasonable starting point on the basis:

  • this is the default remote name used by GitHub and Gitlab
  • it allows things to work where there are multiple remotes (else, which remote would it choose?)
@rfay

This comment has been minimized.

rfay commented Nov 24, 2018

The remote name "origin" is absolutely arbitrary (although ever-so-widely used), and should not be a fundamental assumption. Just a --remote= 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.

@myitcv

This comment has been minimized.

Member

myitcv commented Nov 24, 2018

@rfay

should not be a fundamental assumption
...
Just a --remote= arg would solve the problem and make it explicit that go mod init is dependent on the remote

go mod init is documented as follows:

usage: go mod init [module]

Init initializes and writes a new go.mod to the current directory,
in effect creating a new module rooted at the current directory.
The file go.mod must not already exist.
If possible, init will guess the module path from import comments
(see 'go help importpath') or from version control configuration.
To override this guess, supply the module path as an argument.

Therefore, I don't think it's accurate to describe go mod init as being dependent on the remote configuration. Nor do I think we can describe the searching for a git remote called "origin" as a fundamental assumption. With no module path provided, go mod init's behaviour is, at best, a guess. And if the guess is bad you can supply the module path.

go mod init with zero arguments is not, I suspect, going to be a command that people run every day. Indeed I suspect the most common use of go mod init with no args will be converting from another dependency management solution to Go Modules.

Hence to my mind the current behaviour of go mod init is good enough. More flags, config options etc run the risk of bloating what is a very basic command.

But I'll leave this for @rsc and @bcmills to opine.

@rfay

This comment has been minimized.

rfay commented Nov 24, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment