auto install doesn't always work

[OneOfOne]

Most of the time I'm working on multiple packages in the same time and the work flow goes like this:

• libA: I need func libB.XX()
• switch to libB and add XX
• switch back to libA, try to auto complete and either I get completion without the new func or get "libB is not a valid type".
• switch to libB and run go install ./... manually.
• libA's libB completion works now.

I'm using VSCode, however the issue is mainly with gocode, I got the same result with neovim.

[mdempsky]

I take it you're using nsf/gocode's "autobuild" feature? If so, it's not surprising it doesn't work with mdempsky/gocode: I removed all of the config options. :)

Other tools like vet, gotype, and oracle/guru rely on up-to-date package objects, so I think it's appropriate for gocode to do this too. I suggest that a separate tool should be responsible for ensuring that all of a package's dependencies are up-to-date. Then that single tool can optionally be used by editors before invoking not just gocode, but those other tools too.

[kostya-sh]

FYI if you use emacs with flycheck you can set flycheck-go-build-install-deps to t to automatically install package dependencies on save.

[OneOfOne]

I use vscode-go.

IMHO the auto install feature should be there, or at least optional being off by default, but I understand it is your package.

[mdempsky]

@kostya-sh I think that's close but not exactly what @OneOfOne wants (not to mention for the wrong editor ;)). In their use case, after saving a change to libB, it sounds like flycheck-go-build-install-deps would only install libB's dependencies. But for gocode to give up-to-date suggestions within libA, libB itself needs to be reinstalled too.

@OneOfOne I'm definitely sympathetic to the desire for gocode to Just Work in the scenario you described. But like I said, I don't think it's appropriate for gocode to need to provide it. It would be redundant and bad engineering practice for every Go analysis tool to need to reimplement this functionality.

I suggest you file a feature request with vscode-go (and feel free to CC me and/or reference this issue) to support auto-installation of dependencies.

[kostya-sh]

On May 21, 2016 8:27 AM, "Matthew Dempsky" notifications@github.com wrote:

@kostya-sh I think that's close but not exactly what @OneOfOne wants (not
to mention for the wrong editor ;)). In their use case, after saving a
change to libB, it sounds like flycheck-go-build-install-deps would only
install libB's dependencies. But for gocode to give up-to-date suggestions,
libB itself needs to be reinstalled too.

Yes, not exactly the same, autocomplete will pick up changes in libB only after flycheck runs for libA. I mentioned this only to show that there are ways for editors to provide auto install functionality.

[myitcv]

@mdempsky just out of interest, how do you solve this problem of keeping package objects up-to-date?

[mdempsky]

@myitcv Currently I just run "go install" manually as necessary.

[myitcv]

@mdempsky 👍 does the job!

I'm probably going to hack together something that recursively watches a certain pattern (*.go by default) and triggers a go install for the containing package unless that package is main each time a change is detected - finding myself hitting this a lot given my current setup.