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

AutoComplete un-imported packages based on go.mod #1902

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@uudashr
Contributor

uudashr commented Sep 1, 2018

Initial support for go modules.

@uudashr uudashr changed the title from Autocomplete dependencies based on go.mod to Autocomplete un-imported packages based on go.mod Sep 1, 2018

@uudashr uudashr closed this Sep 1, 2018

@uudashr uudashr reopened this Sep 1, 2018

@uudashr uudashr changed the title from Autocomplete un-imported packages based on go.mod to AutoComplete un-imported packages based on go.mod Sep 1, 2018

@uudashr uudashr referenced this pull request Sep 2, 2018

Closed

Go module support #8

@ramya-rao-a

Thanks for jumping on this @uudashr!

Correct me if I am wrong, I was under the assumption that when modules are enabled, then one can only import packages that are defined in the module or the ones in the standard library.

With the current change, packages from the GOPATH will also be included regardless of whether the current file is under the GOPATH or not

@uudashr

This comment has been minimized.

Contributor

uudashr commented Sep 2, 2018

Ya.. correct. Just figure out.
Need to remove all the packages from GOPATH, should only shows from GOROOT.

For more fine-grained control, the module support in Go 1.11 respects a temporary environment variable, GO111MODULE, which can be set to one of three string values: off, on, or auto (the default). If GO111MODULE=off, then the go command never uses the new module support. Instead it looks in vendor directories and GOPATH to find dependencies; we now refer to this as "GOPATH mode." If GO111MODULE=on, then the go command requires the use of modules, never consulting GOPATH. We refer to this as the command being module-aware or running in "module-aware mode". If GO111MODULE=auto or is unset, then the go command enables or disables module support based on the current directory. Module support is enabled only when the current directory is outside GOPATH/src and itself contains a go.mod file or is below a directory containing a go.mod file.

@ramya-rao-a

This comment has been minimized.

Member

ramya-rao-a commented Sep 2, 2018

So I am guessing we need to

  • Identify if current package is using modules or not
  • If it uses modules, then we can run go list with the GOROOT as cwd and combine the results with that of go list -m all with current package as cwd.

The identification of whether current package is using modules or not, should be done in util.ts file just like getGoVersion

@ramya-rao-a

This comment has been minimized.

Member

ramya-rao-a commented Sep 2, 2018

I cloned https://github.com/golang/example/ outside of my GOPATH

  • Ran go mod init and go mod tidy in the example folder
  • cd hello and go build to ensure that the hello package builds without any issues
  • The file hello/hello.go imports the stringutil package, but if I run go list -m all, the stringutil is not listed.

Since this PR relies on go list -m all, how is the above case going to be supported?

@uudashr

This comment has been minimized.

Contributor

uudashr commented Sep 2, 2018

@ramya-rao-a what is the goal of browsePackages() we need to decide what it should shown on the browsePackages() under Go 1.11, is it the all packages on the GOROOT + GOPATH?

What if we are opening file under go modules project, does the result going to be different ex: GOROOT + modules

@ramya-rao-a

This comment has been minimized.

Member

ramya-rao-a commented Sep 4, 2018

Yes. Let's keep things consistent and make all the 3 exported functions from goPackages.ts to

  • return packages from GOROOT and GOPATH if current package is under GOPATH
  • return packages from GOROOT and modules if modules feature is being used
@dreamheld

This comment has been minimized.

dreamheld commented Sep 5, 2018

Is this coming online soon? It'd be nice for VSC to work with the .mod files!

@avence12 avence12 referenced this pull request Sep 6, 2018

Closed

Support Go modules #1532

@uudashr

This comment has been minimized.

Contributor

uudashr commented Sep 10, 2018

Hopefully soon

@dreamheld

This comment has been minimized.

dreamheld commented Sep 19, 2018

Hopefully soon

Eh! I just went ahead and imported your files into my current Go plugin. Couldn't wait for the 'official' release. Great work, man! Everything is working just swimmingly! Love it!

@edp1096

This comment has been minimized.

edp1096 commented Sep 20, 2018

Works great too.
I'm using inferGopath and using original GOPATH as only an area of extension's gotools.

@ramya-rao-a

This comment has been minimized.

Member

ramya-rao-a commented Sep 22, 2018

@uudashr Turns out that if you use go list all without the -m flag, it gives you all the available packages for the current module. So we don't need to first fetch all the std lib and then join it with the result of go list -m all.

Also, the current solution in this PR doesn't make use of the caching system we put in place earlier.

I am closing this PR in favor of 0a9001f which covers the above concerns.

Do take a look at that commit and share any feedback you have.

Others,
Please do try the latest beta version of this extension which has the above fix and share any issues you find.

Also see
#1532 (comment)

@uudashr

This comment has been minimized.

Contributor

uudashr commented Sep 23, 2018

Still we have missing piece here.
go list -m all show the list of modules not packages.

@ramya-rao-a

This comment has been minimized.

Member

ramya-rao-a commented Sep 23, 2018

Note to others: this is being followed up in #1937

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment