interesting module build issue when trying examples quickly #43829

marystern · 2021-01-21T15:52:40Z

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).

The text was updated successfully, but these errors were encountered:

seankhliao · 2021-01-21T17:41:30Z

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 · 2021-01-26T13:24:48Z

@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 · 2021-01-26T13:50:23Z

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 · 2021-02-17T20:34:45Z

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 · 2021-02-17T21:37:59Z

You always need go.mod

marystern · 2021-02-21T13:18:59Z

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

golang/go#37554 golang/go#43829

marystern · 2021-05-21T13:14:35Z

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

seankhliao closed this as completed Jan 21, 2021

AZ-X added a commit to AZ-X/pique that referenced this issue Mar 19, 2021

self-mods; emerge stammel; clean up; unify 'temporary'

af36f36

golang/go#37554 golang/go#43829

marystern mentioned this issue May 21, 2021

cmd/go: package is replaced but not required #44529

Closed

golang locked and limited conversation to collaborators May 21, 2022

gopherbot added the FrozenDueToAge label May 21, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

interesting module build issue when trying examples quickly #43829

interesting module build issue when trying examples quickly #43829

marystern commented Jan 21, 2021

seankhliao commented Jan 21, 2021

marystern commented Jan 26, 2021 •

edited

seankhliao commented Jan 26, 2021

marystern commented Feb 17, 2021 •

edited

seankhliao commented Feb 17, 2021

marystern commented Feb 21, 2021

marystern commented May 21, 2021

interesting module build issue when trying examples quickly #43829

interesting module build issue when trying examples quickly #43829

Comments

marystern commented Jan 21, 2021

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

Conclusion

seankhliao commented Jan 21, 2021

marystern commented Jan 26, 2021 • edited

seankhliao commented Jan 26, 2021

marystern commented Feb 17, 2021 • edited

seankhliao commented Feb 17, 2021

marystern commented Feb 21, 2021

marystern commented May 21, 2021

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

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

marystern commented Jan 26, 2021 •

edited

marystern commented Feb 17, 2021 •

edited