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

cmd/go: go should also work with expanded modules in $GOPATH/src #30174

Closed
nim-nim opened this issue Feb 11, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@nim-nim
Copy link

commented Feb 11, 2019

Even though modules are the future there are still large codebases out there not modularized or likely to be modularized soon.

So the same vetted code can be consumed both by module-aware go code and not module-aware go code.

It's very annoying that in module mode, the go command will refuse to read go.mod files in $GOPATH/src/modulename/go.mod, and forces you to deploy the same code in two different format to accommodate both kinds of consumers

@bcmills bcmills changed the title go should also work with expanded modules in $GOPATH/src cmd/go: go should also work with expanded modules in $GOPATH/src Feb 11, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 11, 2019

The go command does not refuse to read go.mod files in GOPATH/src. You just have to tell it to do so explicitly by setting GO111MODULE=on (instead of leaving it set to auto).

@bcmills bcmills closed this Feb 11, 2019

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

So in auto mode, it go will switch to module mode in the presence of a go.mod file, for the directory you're in, but not for $GOPATH ? That's quite unintuitive.

But anyway it does not seem to work

$ export GO111MODULE=on
$ go build -o myapp main.go
build <foo>: cannot find module for path github.com/jawher/mow.cli
$ cat $GOPATH/src/github.com/jawher/mow.cli/go.mod
module github.com/jawher/mow.cli

require (
        github.com/davecgh/go-spew v1.1.1 // indirect
        github.com/pmezard/go-difflib v1.0.0 // indirect
        github.com/stretchr/testify v1.2.2
)
@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

In module mode, we only read source files from the current module and its listed requirements. The requirements are resolved from modules, not from GOPATH, although you can certainly use replace directives in your go.mod file to point into GOPATH if you so desire.

If go build isn't working for some specific module, please file a separate issue with concrete file and directory contents and a complete list of commands that we can run to reproduce the problem. (A go build command by itself is not nearly enough information.)

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

Well that's pretty much what I wrote in my initial message

Module mode as it exists today forces the redeployment of the same code in a different format on the filesystem. You can not have a library of audited go code in a directory, that can be used both from modularized golang code and non modularized golang code, because module mode ignores existing go.mod files in GOPATH (adding manual replace calls for pretty much every bit of third party code that you need does not scale and leaks site-specific information in the commited codebase).

That makes converting codebases to module mode more expensive from a logistics point of view that it should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.