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

Features that rely on gopls will not work correctly outside of GOPATH or a module. #2301

Closed
desdic opened this issue May 20, 2019 · 14 comments · Fixed by #2302
Closed

Features that rely on gopls will not work correctly outside of GOPATH or a module. #2301

desdic opened this issue May 20, 2019 · 14 comments · Fixed by #2302

Comments

@desdic
Copy link
Contributor

desdic commented May 20, 2019

call go#util#EchoWarning('Features that rely on gopls will not work correctly outside of GOPATH or a module.')

For some reason I get this warning even if my project is setup as a module. vim-go works fine but I have to press enter to continue every time I open a file

@saschagrunert
Copy link

The main issue on my side is that the go list command fails because the root directory of my go projcet does not contain any go files:

let [l:out, l:err] = go#util#Exec(['go', 'list'])
execute l:cd fnameescape(l:dir)
if l:err != 0
return -1
endif

@peterhellberg
Copy link

peterhellberg commented May 20, 2019

I'm also seeing this issue. (The project does not have any go file in its root directory)

Should go list ./... be called instead?

let [l:out, l:err] = go#util#Exec(['go', 'list', './...'])

bhcleek added a commit to bhcleek/vim-go that referenced this issue May 20, 2019
Warn the user and do not initialize gopls only when in using a null
module and in module mode.

Fixes fatih#2301
@saschagrunert
Copy link

saschagrunert commented May 20, 2019

I'm also seeing this issue. (The project does not have any go file in its root directory)

Should go list ./... be called instead?

let [l:out, l:err] = go#util#Exec(['go', 'list', './...'])

I'm not sure if this is the right solution. I mean it now matches the first package, does everything works as intended after this change?

Ah I see it has been fixed with another fix. So I assume this is fine now.

@rbcrwd
Copy link

rbcrwd commented May 21, 2019

Not to reopen this, but to perhaps save someone else some steps.

Vim's getcwd() call always returns the physical directory, and I can't find a way to override this. That means for those random few of us that have made GOPATH/src (or subdirectories thereof) a symlink get this message as well as other subtly broken behavior in vim-go features that use getcwd().

@bhcleek
Copy link
Collaborator

bhcleek commented May 21, 2019

symlinks in GOPATH are not supported by vim-go, because it's not supported by Go: golang/go#15507 (comment)

@rbcrwd
Copy link

rbcrwd commented May 22, 2019

Please note, I'm not asking vim-go to support it, I'm simply leaving breadcrumbs for the next person that runs up against this.

That said, this isn't the same problem space. Your linked bug and its siblings are about Go explicitly supporting symlinks. This is about vim (and therefore vim-go) behaving differently than Go does by invariably resolving symlinks rather than just ignoring them and following whatever path you use. Whether by design or not, Go is perfectly happy with GOPATH/src being a symlink, whereas vim will resolve it to its physical location and produce different behavior than the canonical Go command-line tooling.

@silas
Copy link

silas commented May 24, 2019

Is there a way to disable this feature completely? I couldn't find anything obvious in the documentation or autoload config file.

This warning adds a forced 1 second delay and prompt if you're just editing a lonely go file.

Example

$ cd $( mktemp -d )
$ cat << EOF > hello.go
package main
func main() { println("hello world") }
EOF
$ vim hello.go

Output

"hello.go" 5L, 52C
vim-go: Features that rely on gopls will not work correctly outside of GOPATH or
 a module.
Press ENTER or type command to continue

@santosh
Copy link
Contributor

santosh commented Jun 5, 2019

I'm in similar condition as @silas. Sometimes I want to edit standalone .go file, which of course is not inside GOPATH.

How can we disable this warning? Or at least prevent it from opening the file.

A warning shown on statusline after opening the file would also serve the purpose of warning the user.

@vkorchagin
Copy link

The warning can be disabled with this line in .vimrc:

let g:go_null_module_warning = 0

@weienjun
Copy link

weienjun commented Jun 7, 2019

I have a similar question :vim-go :Features that rely on gopls will not work correctly in a null module
who can help me ,thanks

@HelperInCa
Copy link

I have a similar question :vim-go :Features that rely on gopls will not work correctly in a null module
who can help me ,thanks

same problem!

@pierDipi
Copy link

I have a similar question :vim-go :Features that rely on gopls will not work correctly in a null module
who can help me ,thanks

Same problem!

@raymonlai
Copy link

Same problem!

@stamblerre
Copy link
Contributor

The latest version of gopls does support null modules. To get the latest version, run go get -u golang.org/x/tools/gopls@master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.