interesting module build issue when trying examples quickly

[marystern]

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

$ go version
go version go1.15.6 linux/amd64

Does this issue reproduce with the latest release?

don't know.

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

go env Output

$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GO111MODULE=""

What did you do?

I tried to build and run a simple example program for "go-prompt" as a standalone file in a new, empty directory.
ref:
c-bata/go-prompt#215

(I often do this to quickly test out a new package: copy an example and just try to run it to see if it simply works. In this case it didn't, and I would normally simply ignore the package and assume that it was unmaintained/immature/poorly tested. Luckily, in this case I persevered and discovered quite an interesting thing regarding how an apparently good looking module dependency can fail without obvious reason.)

What did you expect to see?

It should have built (with a specified older 1.1.0 module version, which had an older, different function signature), but failed (due to an API change)

What did you see instead?

A confusing build failure (it tried to build against code that was not in the specified module version!).

Conclusion

Note that I think this was resolved by forcing "module-mode" for the build ("to be confirmed" though..)

I'm raising this bug because this is a very simple error to make (ie not create a go.mod file simply to run a one-file sample test), and more significantly, a very odd, tricky, confusing thing to analyze/debug/fix: I almost gave up, but luckily, on this occasion, it piqued my interest.

Maybe there should/could be some kind of warning when the non-module mode is using a latest version of a module rather than the specified modules in an imported package?

I realize that this is a temporary annoyance (ie until the world moves over to modules, but please can you confirm how this would work in the New World, ie do you always have to do a go mod init simply to run a one-file test? This is an uncomfortable user-experience and a new barrier to entry...)

P.S. Can you confirm that my guess is right (ie that non-module mode would pull in the latest version of a module and hence ignore the careful dependency management that someone has tried to set up?) Also, I couldn't find this documented anywhere (luckily I remembered reading something about it a while ago).

[seankhliao]

If you use go1.16+ (you can try the beta now), the go command will default to module mode:

» go build .
go: cannot find main module, but found .git/config in /home/user/testrepo-232
	to create a module there, run:
	go mod init

and yes, in GOPATH mode, the go command has no awareness of versioning, which is why we have modules now

seeing as this is not going to be an issue in the next release, I'm going to close this, please comment/reopen if you disagree

[marystern]

@seankhliao Thanks for that info.

Does this mean that the library I'm using should therefore be dependent on version go 1.16?

Hence, does this also mean that ALL module-dependant libraries should probably bump up their go-lang version specs in their go.mod files to 1.16? (Looks like 1.16 is the first go version that will fully work with modules correctly?)

.. I think this might be some important guidance for creating modules from now on... (or does it not make a difference anyway as it's not using module mode)?

[seankhliao]

What matters is if you the end user are in module mode. If you're not, then go doesn't care about versions no matter what the libraries say they want. If you are then it will try to respect the requested versions.

go1.16 (the tool version) makes module mode the default, you can get the same behavior now if you set GO111MODULES=on

[marystern]

Hi, Can we re-open this (sorry, I'm not sure how to do that)?

With go1.16 (released version), I get the following problem (if I delete the go.mod and go.sum files). Apparently, "go get" is no longer sufficient to pull in a module! Is this expected behavior (seems odd to me)?

$ go version
go version go1.16 linux/amd64

$ cat prompt.go 
package main

import (
	"fmt"
	"github.com/c-bata/go-prompt"
)

func completer(d prompt.Document) []prompt.Suggest {
	s := []prompt.Suggest{
		{Text: "users", Description: "Store the username and age"},
		{Text: "articles", Description: "Store the article text posted by user"},
		{Text: "comments", Description: "Store the text commented to articles"},
	}
	return prompt.FilterHasPrefix(s, d.GetWordBeforeCursor(), true)
}

func main() {
	fmt.Println("Please select table.")
	t := prompt.Input("> ", completer)
	fmt.Println("You selected " + t)
}

$ go get github.com/c-bata/go-prompt
$ go run prompt.go 
prompt.go:6:2: no required module provides package github.com/c-bata/go-prompt: working directory is not part of a module

The only thing I can see in the docs is this:

"go get example.com/mod@patch now requires that some version of example.com/mod already be required by the main module. (However, go get -u=patch continues to patch even newly-added dependencies.) "

.. but that sounds like it's only for explicit module/patch levels rather than for any go get?

Also the docs explicitly state:
"Module-aware mode is enabled by default, regardless of whether a go.mod file is present in the current working directory or a parent directory. "

.. I'm confused (again)! :)
(Sounds like you do sometimes need a go.mod to simply run a file?? :( )

[seankhliao]

You always need go.mod

[marystern]

..if that's the case, the docs need revising to make that clear!!

[marystern]

Note: 1.16 seems to have broken this approach! ref: #44529