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 https://github.com/golang/go/issues/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 b38ad9c5fa95c04b97c8c3fc3f248338f96ab07b 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?