go.inferGopath does not work on opening a different folder

[ziffusion]

go.inferGopath infers the GOPATH when you first open a folder in vscode. But then if you open a different folder, it does not infer the GOPATH from the new folder path. GOPATH remains unchanged.

Steps to recreate:

1. Open vscode, and open a folder. Check that GOPATH is inferred correctly from the folder path.
2. In the same session, open a different folder. Check that GOPATH is unchanged. It is not inferred correctly from the new folder path.

[codmajik]

for GOPATH to be inferred correctly the new folder would have to be in a valid gopath.

ex: /home/user/gopath/[src]/github.com/myusername/myproject gopath is inferred by looking for [src] in the path, which is done of vscode-go activation.

So if it doesn't change either vscode-go is not activatated, ie. no go file is opened yet or the path doesn't contain an src.

[ziffusion]

Thanks for the explanation. But it doesn't seem to be behaving that way. I,m on OSX by the way.

I just opened a file with the following path:

/Users/xxx/ws/yyy/go/src/xxx/ondemand/service/tags/tags-server/version_data.go

When I check the gopath, it is set to:

Current GOPATH: /Users/xxx/ws/go

It behaves erratically. I've seen it say "inferred path" and show the correct path at times. But when I change the folder back and forth a few times, the GOPATH does not change the way it should. I do open a file after opening a different folder.

[codmajik]

that is very strange, I am not unable to reproduce this.

I have opened folders in the same gopath and separate gopath, still not able to reproduce this. I even tried with a new user account.

Here is the code inferGoPath that handles this, its simple and straight enough to not contain any ambiguity. Maybe its a platform specific issue.

BTW: the GOPATH is inferred from the current workspace path not the file path.

Anyone else reading this can you try with an OSX to confirm.

[ziffusion]

All right, I ran the extension under the debugger, and it seems like what I didn't realize was that you were saying that the folder opened in vscode has to be src or something below that in the tree for this to work. For some reason I missed that.

It may help to point this out in the docs.

Otherwise, you can resolve this one as a non issue.

[ramya-rao-a]

@ziffusion So if you were not opening a folder under src, then the folder you did open, that wouldnt be under a valid GOPATH to begin with. So what was the expectation?

[ziffusion]

@ramya-rao-a Well, a few things messed me up.

1. Docs don't describe the behavior of this setting, and 762 says that it emulates GoSublime use_gs_gopath. So I looked at GoSublime docs, and in all the examples there, the tree is rooted in a directory called go. I sort of assumed that that's how the extension figured out the root, by looking for go. I then renamed my workspace roots to be called go, and started the editor at the root (in go). You folks look for src (which makes sense); I should have been one level below in the tree in src.

2. I was also under the impression that the extension inferred GOPATH from the path of the file. You folks look at only the path of the workspace, and that too only when one opens a file. This is somehow confusing (leads one to think that the inference has something to do with the file path). And GoSublime may go by file path (dunno).

In any case, it would be good to clarify the behavior of this setting in the docs (for folks like me who don't have any context).

Something like the following may work.

If go.inferGopath is set to true, the extension will try to infer the GOPATH from the path of the workspace i.e. the directory opened in vscode. It searches upwards in the path for the src directory, and sets GOPATH to one level above that.

For example, if your project looks like /aaa/bbb/ccc/src/..., then opening the directory /aaa/bbb/ccc/src (or anything below that) will cause the extension to search upwards, find the src component in the path, and set the GOPATH to one level above that i.e. GOPATH=/aaa/bbb/ccc.

Note that GOPATH is inferred when you first open a file with the go extension.

This setting is useful when you find yourself opening up different projects in vscode. It causes the extension to set the GOPATH for each project automatically.

[ramya-rao-a]

@ziffusion Thats very well summed up, thanks a lot. I have used what you have written here in https://github.com/Microsoft/vscode-go/wiki/GOPATH-in-the-VS-Code-Go-extension and linked the wiki from the README

@codmajik When there is no workspace opened and there is just a single file open in VS Code, we can still infer the GOPATH from the filepath. Thoughts?

[codmajik]

@ziffusion @ramya-rao-a, sure, we can infer from the filepath, I would push an update.

Should this be configurable?

[ziffusion]

@ramya-rao-a @codmajik

Not sure if having it configurable is of value or not. I suppose, whatever makes things work well on the least-surprise principle, should be OK.

So, how do you think that inferring from a file might work? At what point would the GOPATH be set? Considering that you can open a file from outside the workspace as well.

1. Would it be when any file is opened? Or when a file is first opened in a workspace? How would you decide if the opened file is in the workspace or not?
2. Or do you try and set the GOPATH before an operation that needs GOPATH?
3. Or does it make sense to set it from the file path each time the user changes tabs.

Maybe, setting it once from the workspace, when a directory is opened in vscode, is fine. Should the user have the ability to override it? Or at least reinitialize it? Maybe by a command like go infer GOPATH.

Another issue seems to be that the GOPATH setting is not visible to the debugger. That seems like a serious handicap, do you think?

[codmajik]

@ramya-rao-a @ziffusion

1. It would only work when no workspace is open.
2. GOPATH is set on initialization of the vscode-go, so the first time a go file is opened in a non-workspace vscode window, we infer from the file's path.
3. Due to 2, we can't set it each time tab is changed. It would require to much change.

Another issue seems to be that the GOPATH setting is not visible to the debugger. That seems like a serious handicap, do you think?

That is very strange, I don't use the debugger that much. inferGopath is part of the global GOPATH detection scheme. it is right where the effect of go.gopath and co are applied.

[ziffusion]

@ramya-rao-a @codmajik

1. It would only work when no workspace is open
2. so the first time a go file is opened in a non-workspace vscode window, we infer from the file's path.

So, this is when a person opens up a file in a window all by itself. What happens if he opens up another file in a different tab (but same window)?

That is very strange, I don't use the debugger that much. inferGopath is part of the global GOPATH detection scheme. it is right where the effect of go.gopath and co are applied.

Actually, I said that based on some docs you have on the wiki. It says there:

The debug adapter in the Go extension does not have access to your User/Workspace settings. Therefore, the only GOPATH the debugger is aware of is the one set as environment variable outside of VS Code.

[ramya-rao-a]

I initially thought we could have the GOPATH inferred from the file path only when there is no folder opened as in the file is open in a VS Code all by itself. But @ziffusion brings up a good point, we could have multiple Go files open, where would the GOPATH be inferred from?

It would be better to leave this as is. i.e inferGopath only works if there is a folder opened in VS Code.

About the debugger not able to read user/workspace settings, I have logged #840 to dig a little deeper and get a better understanding regarding the why and how around the issue.

Closing this issue as there are no action items left. Thanks for the great discussion though :)

Happy Coding!