GO111MODULE=on support

[dmitshur]

This is merely a question, not a feature request.

I've read SUPPORT.md, searched through issues, and didn't find an answer as to whether GO111MODULE=on mode is meant to be supported (or planned to be supported). I wanted to ask about that.

Thank you!

[DisposaBoy]

Go modules is not supported beyond whatever magic is in go/build. I planned to support it, and have looked at it multiple times since the introduction of modules but came up against show-stopping bugs and frustration like golang/go#29452.

At this time I don't understand how modules work because it's under-documented and the devs seem to be making it up as they go, so I will wait until after the release of go1.12.1 to re-evaluate the situation. Hopefully they'll have sorted out some of the mess by then.

[dmitshur]

Thanks for answering.

Would you prefer I close this issue, since my question has been answered, or keep it open in case other people have the same question?

[DisposaBoy]

Thanks for answering.

NW.

Would you prefer I close this issue, since my question has been answered, or keep it open in case other people have the same question?

I'll leave it open until I make a decision and update SUPPORT.md.

[kortschak]

Is there any update on this? It looks like we are heading towards a world where modules are on by default by soon after the middle of this year (Go 1.13 release is planned for August). This is not that far away.

[dmitshur]

The latest update on the GO111MODULE plan is here.

[kortschak]

Thanks. The reason I ask is because, apart from the looming change that will break GoSublime unless the user sets GO111MODULE=off, there are other tools that will now only work if GO111MODULE=on. An example of this is SublimeLinter's golangcilint plugin that fails to lint packages with canonical imports unless GO111MODULE is on because it writes the buffer to a temporary directory that can then be loaded by x/tools/packages. packages fails to load packages that disagree with their canonical import (I don't entirely understand why turning on module support gets around this, @dmitshur can you explain this?).

[dmitshur]

@kortschak The answer to your question is at the bottom of https://golang.org/cmd/go/#hdr-Import_path_checking section:

Import path checking is also disabled when using modules. Import path comments are obsoleted by the go.mod file's module statement.

If it's okay to discuss alternative solutions since GoSublime does not support module mode at this time, another way to consider getting some module support in Sublime Text could be via a Language Server Protocol (LSP) plugin such as https://github.com/tomv564/LSP and the gopls LSP server. I haven't tried that approach yet, but I'd like to sometime.

[kortschak]

Thanks.

[kortschak]

An update on this. If I add a go.mod file to the root of Packages/GoSublime, everything works with GO111MODULE=on.

[jvsteiner]

@kortschak can you elaborate a little more on how and what exactly you got working? Are you saying that you were able to get autocomplete to work in projects using modules which are outside the GOPATH?

[kortschak]

It seems so. Starting from a file that is outside $GOPATH/src I can Ctrl+. Ctrl+G to go to definitions and autocomplete works for me.

I have not tried completely outside $GOPATH (I set GOPATH to ~) and have not tried without GOPATH set.

[agnivade]

Just wanted to mention that on a project outside my GOPATH, my cursor stutters when I write code.

As in, the CPU spikes up shortly due to which the cursor movement is not smooth. It goes away if I disable the golang.Gocode reducer. Is this expected for projects outside GOPATH or am I supposed to do something else ?

[wjm3219]

Is GO111MODULE=on still unsupported by now?
Gocode won't auto-complete code when use go module (outside of $GOPATH), but it runs well in $GOPATH.

[DisposaBoy]

I dusted off my experimental code from December/January and added experimental support for auto-completion in go modules, but it needs testing before release. If you want to try it out, you'll need to temporarily switch to the next branch.

[wjm3219]

@DisposaBoy I've tried next branch, it works well outside of GOPATH.
Thank u very much.

[alesstimec]

I'm having problems with modules and code completion (i am on the "next" branch). Did anybody get that working?

[DisposaBoy]

@alesstimec What problems are you having?

[alesstimec]

@DisposaBoy sorry for a late answer.. but autocompletion seems to work occasionally for project using go modules.. far from what was available for non-module projects.. maybe it's just my configuration...

[DisposaBoy]

@alesstimec Are you able to reliably reproduce the issue?

There are a few changes yet to be released - which improves things a bit - but what's released should work on pure-go packages and partially with CGO packages.

Maybe setting ImporterMode to golang.KimPorter directly will help.

&golang.MarGocodeCtl{
	ImporterMode:          golang.KimPorter,
}

[alesstimec]

Hi @DisposaBoy..
Thank you for that suggestion.. it improved things a bit.. but now i'm faced with a "pre_save timeout on view" error..

[DisposaBoy]

@alesstimec What does your config look like? pre_save is when we do fmt so it's most likely something like goimports taking too long.

I don't use goimports but if there's a way for me to reproduce this, I can have a look.

[tooolbox]

I am using modules outside of a GOPATH.

Checking out the next branch (commit b38ad9c at this time) and configuring Margo with this:

&golang.MarGocodeCtl{
	ImporterMode:          golang.KimPorter,
}

Has resulted in a lot of my woes being handled. Auto-completion working great, at least with the stdlib and within my module. Still working on getting external module auto-completion working.

---

It's interesting, seems to work fine for some packages and less for others. Prefers things that I have listed in my go.mod but occasionally works if they're not. Sometimes I see this stuff in the console:

[12:37:44] margo: agent#021: log: DBG: margocode.go:394: margocode: pkgInfo("github.com/cockroachdb/errors", "/Users/me/git/project/folder"): cannot find package "github.com/cockroachdb/errors" in any of:
[12:37:44] margo: agent#021: log: 	/usr/local/Cellar/go/1.13/libexec/src/github.com/cockroachdb/errors (from $GOROOT)
[12:37:44] margo: agent#021: log: 	/Users/codewarrior/go/src/github.com/cockroachdb/errors (from $GOPATH)

[DisposaBoy]

@tooolbox If you're able to reliably reproduce it it would be very helpful. I suspect one of the unreleased changes I have locally would help and/fix this.

[tooolbox]

I found one thing, which is that it doesn't handle replace directives in a go.mod file.

Empty directory, write a main.go:

package main

import (
	"os"
	"github.com/cockroachdb/errors"
)

func main() {
	if err := epicfail(); err != nil {
		os.Exit(1)
	}
}

func epicfail() error {
	return errors.New("This failed")
}

With a go.mod file:

module local

go 1.13

require (
	github.com/certifi/gocertifi v0.0.0-20191021191039-0944d244cd40 // indirect
	github.com/cockroachdb/errors v1.2.4 // indirect
	github.com/cockroachdb/logtags v0.0.0-20190617123548-eb05cc24525f // indirect
	github.com/getsentry/raven-go v0.2.0 // indirect
	github.com/gogo/protobuf v1.3.1 // indirect
	github.com/pkg/errors v0.8.1 // indirect
)

// replace github.com/cockroachdb/errors => github.com/tooolbox/errors v1.2.4-0.20191014220846-28534da25f14

(I did one go run main.go to get the juices flowing.)

I get auto-completion on the cockroachdb/errors package, but when I un-comment that replace directive and type errors., this fills the console:

[12:20:00] margo: agent#022: log: DBG: margocode.go:394: margocode: pkgInfo("github.com/cockroachdb/errors", "/Users/me/git/subl_test"): cannot find package "github.com/cockroachdb/errors" in any of:
[12:20:00] margo: agent#022: log: 	/usr/local/Cellar/go/1.13/libexec/src/github.com/cockroachdb/errors (from $GOROOT)
[12:20:00] margo: agent#022: log: 	/Users/me/go/src/github.com/cockroachdb/errors (from $GOPATH)

Is that helpful @DisposaBoy ?

[DisposaBoy]

@tooolbox Thanks for the repro.

I've pushed some of my local changes/experimentation onto the next branch. It should work for this case as well.

[DisposaBoy]

The latest release v20.01.01 should hopefully resolve all bugs reported in this issue.

[zoli]

The autocomplete still doesn't seem to work with go modules(in my case most of the times).
For example for github.com/amonsat/gtmetrix package autocomplete it looks in $GOPATH/src/github.com/amonsat/gtmetrix but regarding go.mod file it should look in $GOPATH/pkg/mod/github.com/amonsat/[email protected] 8130828-e8fdd1aa4fc2/

What I'm saying is based on 9o://9o output.

[DisposaBoy]

@zoli How can I reproduce the issue?

I just tried:

• go mod init test module...
• go get ...gtmetrix...
• import ...gtmetrix...

and autocompleting gtmetrix._ works for me.

[zoli]

* go mod init test

Done the exact steps you mentioned and I cant get any autocompletion. I see this error in 9o:

guru: cannot find package "github.com/amonsat/gtmetrix" in any of:
		/usr/lib/go/src/github.com/amonsat/gtmetrix (from $GOROOT)
		/home/zoli/.go/src/github.com/amonsat/gtmetrix (from $GOPATH)

[DisposaBoy]

@zoli that error is from guru which is used for the goto definition feature so has no effect on completion. Are you sure you're using the latest version of GoSublime? Also what does your margo.go file look like?

[zoli]

@DisposaBoy Yeah, but I thought not showing any autocompletion and not working go to definition maybe related. The package is on latest commit(96954d1).

This is my margo.go.

Thanks for your help and the great package btw.

[DisposaBoy]

@zoli margo.go looks fine to me.

Try adding the Debug: true, option to the &golang.MarGocodeCtl{...} reducer. It should print some debugging info in the Sublime Text console (not 9o).

Also, from within 9o, what does go env GOMOD GO111MODULE print? guru also works for me so I'm thinking that maybe it could be an environment variable/setup issue.

[zoli]

go env GOMOD GO111MODULE prints off in 9o, but in terminal returns the go.mod file path.

Enabling debug option didn't bring anything in console.

[DisposaBoy]

@zoli Did you explicitly set GO111MODULE?
If go env prints off, it must be set somewhere. Maybe in GoSublime.sublime-settings? ctrl+.,ctrl+5?

[zoli]

@DisposaBoy I don't have any user settings for gosublime. Also except the GOPATH which is set in my shell config file, I have not modified any env variable related to go which I know.

go env GOMOD GO111MODULE returns go.mod file in directories which I initialized them with go mod init test, in other directories it returns empty line.

[DisposaBoy]

@zoli You need to run the go env... command inside Sublime Text (i.e. inside 9o) because GUI apps don't necessarily inherit the env vars from your $SHELL. I wrote an article about this many years ago, including details about what GoSublime does to work around the problem: https://github.com/DisposaBoy/GoSublime/blob/development/articles/shell.md.

AFAIK, if go env GO111MODULE prints off (or any value?), it means it was set somewhere.

If you look in the Sublime Text console ctrl+` after it starts up, you should see some lines like GoSublime r20.03.01-1 sh: using shell env ...GOPATH...etc. These lines are vars that GS loaded from your $SHELL.

From 9o, running the command settings env shows vars that have been set in a settings file somewhere.

Worst-case, I guess you could also set it in the GS env settings ctrl+.,ctrl+5, but then it doesn't work the same as your $SHELL. e.g.

"env": {
    "GO111MODULE": "auto",
}

[zoli]

AFAIK, if go env GO111MODULE prints off (or any value?), it means it was set somewhere.

@DisposaBoy After what you said I looked into the code and I think I might have found the problem. Here Gosublime sets GO111MODULE off and it only returns the value to what it was before only if modSet is true. But in my case GO111MODULE value is empty and modSet is false but this doesn't mean that GO111MODULE is off. Because modSet is false Gosublime won't set GO111MODULE to empty again.

Running os.Setenv("GO111MODULE", modWas) unconditionally solved the problem.

[DisposaBoy]

Thanks for spotting that @zoli. It turns out I had GO111MODULE=auto set and even after unsetting it in my shell, it persisted until I rebooted. I <3 env vars even more than this Go module transition /s.

EDIT: Latest release https://github.com/DisposaBoy/GoSublime/releases/tag/v20.03.09 should fix it.

[zoli]

Pulled the latest release and yes it fixes the problem, Thanks.

[tooolbox]

Comment removed

I'm sorry, everything is working great! Thanks @DisposaBoy ! I have tried out VSCode for Go a few times now and I always throw up my hands in disgust and come back to GoSublime.