GoLand 2019.3.4 Not finding libraries that are in <project_dir>/vendor/


I have project that is working okay with go modules at the command line. But it is failing to find many imports in GoLand. I've confirmed that those libraries are in the <project_dir>/vendor/ folder.

System: Mac OS 10.14.6

GoLand: GoLand 2019.3.4
Build #GO-193.6911.30, built on March 20, 2020
Runtime version: 11.0.6+8-b520.43 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.6
GC: ParNew, ConcurrentMarkSweep
Memory: 2014M
Cores: 4
Registry: run.processes.with.pty=TRUE, ide.completion.variant.limit=500, suggest.all.run.configurations.from.context=true, folding.check.collapse.state.before.placeholder.text=TRUE, ideFeaturesTrainer.welcomeScreen.tutorialsTree=TRUE
Non-Bundled Plugins: BashSupport, PythonCore, com.intellij.kubernetes, mobi.hsz.idea.gitignore, name.kropp.intellij.makefile, org.toml.lang

Project go.mod (partial):

module github.com/operator-framework/operator-metering

go 1.13

require (
cloud.google.com/go v0.44.3 // indirect
github.com/Masterminds/semver v1.4.2 // indirect

There are several replace stanzas as well, can add if needed.

If it helps, I get Run output that is related to the libraries that can't be found:

GOROOT=/Users/btofel/.gvm/gos/go1.13.9 #gosetup
GOPATH=/private/tmp/go #gosetup
/Users/btofel/.gvm/gos/go1.13.9/bin/go list -m -json -mod= all #gosetup
go: github.com/operator-framework/operator-lifecycle-manager@v0.0.0-20191115003340-16619cd27fa5 requires
github.com/openshift/api@v3.9.1-0.20190924102528-32369d4db2ad+incompatible: invalid pseudo-version: preceding tag (v3.9.0) not found

If I type go env at the internal terminal prompt I get:

 (master)$ go env
GOFLAGS=" -mod="
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gb/1lg9cbnj15g32lkhdrhdjbn80000gn/T/go-build098444412=/tmp/go-build -gno-record-gcc-switches -fno-common"

It seems like I would want to set -mod=vendor as I have set for my external terminal env, but I don't know how one would set GOFLAGS items in GoLand

Comment actions Permalink


github.com/openshift/api@v3.9.1-0.20190924102528-32369d4db2ad+incompatible: invalid pseudo-version: preceding tag (v3.9.0) not found

The error comes from `go list`. Is that version actually exists somewhere on in your vendor/ directory only? How did you get it in the vendor directory in the first place?

> It seems like I would want to set -mod=vendor

You can open the settings at `Preferences | Go | Go Modules` and check whether auto-vendor mode is enabled. Still, GoLand will run `go list` without vendor mode as it's required for proper resolution.

Comment actions Permalink

Yes, "Enable vendoring support automatically" is checked. I'd expect any use of a Go tool by the IDE to then respect that and set GOFLAGS="-mod=vendor". We have `replace` stanzas in our `go.mod` specifically to lock the related indirect library imports to a fixed version of an underlying library, those copies were brought into our `<project>/vendor` dir on purpose using `go mod vendor`. Here's from `go help modules` output:

Modules and vendoring

When using modules, the go command completely ignores vendor directories.

By default, the go command satisfies dependencies by downloading modules
from their sources and using those downloaded copies (after verification,
as described in the previous section). To allow interoperation with older
versions of Go, or to ensure that all files used for a build are stored
together in a single file tree, 'go mod vendor' creates a directory named
vendor in the root directory of the main module and stores there all the
packages from dependency modules that are needed to support builds and
tests of packages in the main module.

To build using the main module's top-level vendor directory to satisfy
dependencies (disabling use of the usual network sources and local
caches), use 'go build -mod=vendor'.

Our make process always calls `go mod vendor` and we want the specific versions that are downloaded to be there -- so much so that we commit `<project_dir>/vendor` (a commonly recommended action) to our git repo.

Most important about this is that, I can run the underlying tools by hand with the -mod=vendor flag as I want, but GoLand seems to be processing the output of `go list` for its resolution of the libraries -- to allow tracing through the code and that is currently unavailable for the library in question, even though the library is in fact right there in the vendor dir. So a bug.

Comment actions Permalink

> I'd expect any use of a Go tool by the IDE to then respect that and set GOFLAGS="-mod=vendor". 

Any use except `go list`. 

> Here's from `go help modules` output:

It's about building, not listing. We have to make `go list` without vendoring for proper resolution, then GoLand will resolve things to vendor directory based on this information. If we run `go list` with -mod=vendor, it will break the entire resolution.

At the moment, you can follow that issue: https://youtrack.jetbrains.com/issue/GO-8932, it looks related.


Please sign in to leave a comment.