-2

Some Go text editors and IDEs (in my particular case, JetBrains's GoLand IDE) will automatically delete unused imports on save. This is ordinarily a good thing, because the Go compiler throws errors for unused imports.

However, in the case of the github.com/fxamacker/cbor/v2 import, I believe GoLand gets confused by the v2 at the end, and thinks the import is never used, because there is never any v2.<something> in the file anywhere. So GoLand deletes this import when I save, but then my file fails to compile, because the import I need is gone.

I thought I could fix this with a leading underscore, like this:

import (
        // ... other imports here ...
        _ "github.com/fxamacker/cbor/v2"
)

When I make this change, then GoLand does not delete my import, but then I get errors when I compile:

redacted.go:15:10: undefined: cbor
redacted.go:19:13: undefined: cbor
redacted.go:20:17: undefined: cbor
redacted.go:109:8: undefined: cbor

How can I import this module so that the import isn't auto-deleted by GoLand, and the file can still be compiled?

Shane Bishop
  • 3,905
  • 4
  • 17
  • 47

2 Answers2

0

I just created a project with Goland using cbor/v2 and everything works as expected. I think that you have another configuration problem which is unrelated to that package or Go versioning.

How to reproduce:

In new directory:

$ go mod init q
go: creating new go.mod: module q
$ go get github.com/fxamacker/cbor/v2
go: downloading github.com/fxamacker/cbor v1.5.1
go: downloading github.com/fxamacker/cbor/v2 v2.4.0
...
  • Open that directory as a project in Goland.
  • Create file main.go with contents
package main

func main() {
    var dummy int
    cbor.Marshal(dummy)
}

Goland will add

import "github.com/fxamacker/cbor/v2"

And saving does not remove it.

Edit from comment to make it more visible

It might be that when you run go from the command-line in WSL, it uses a different GOROOT compared to the one that Windows, and thus Goland, uses. You have to tell Goland, for that project, to use the correct GOROOT.

marco.m
  • 4,573
  • 2
  • 26
  • 41
  • Yes, I do have another configuration "error", which is that I am running GoLand on Windows, from code stored on my WSL2 filesystem. GoLand isn't able to see the packages I'm imported in my WSL2 filesystem, which is what causes this problem. – Shane Bishop Jun 24 '22 at 15:47
  • 1
    @ShaneBishop maybe finally I understood what is the problem. It might be that when you run go from the command-line in WSL, it uses a different GOROOT compared to the one that Windows, and thus Goland, uses. You have to tell Goland, for that project, to use the correct GOROOT. – marco.m Jun 24 '22 at 16:20
  • Thanks @marco.m! Setting GOROOT for GoLand fixed everything. I updated my answer to explain that the GOROOT had to be set properly. – Shane Bishop Jun 24 '22 at 22:22
  • @ShaneBishop well, you should have accepted my answer instead ... – marco.m Jun 25 '22 at 16:37
-1

The problem was I had not configured GoLand to know my GOROOT for the WSL2 filesystem that my Go code was stored on. This meant GoLand couldn't resolve any of the imports, and thus it was unable to see that github.com/fxamacker/cbor/v2's package is cbor, which in turn meant GoLand would assume this import was unused, and auto-delete it on save.

Once I configured my GOROOT to \\wsl$\Ubuntu\usr\local\go, it was able to resolve all my imports, and it stopped deleting the github.com/fxamacker/cbor/v2 import on save.

Shane Bishop
  • 3,905
  • 4
  • 17
  • 47
  • 4
    Go sees the name for the package, it must or else it wouldn't compile. The package is called `cbor`, but if GoLand doesn't recognize this it's a bug in GoLand. – JimB Jun 24 '22 at 14:19
  • I don't think this is a bug in GoLand. I am running GoLand on Windows, but my code lives in WSL2, and the imports are in the WSL2 filesystem. So GoLand can't resolve any of the imports, and so GoLand can't tell that the package is called `cbor`. So I guess what I've done is really just created a workaround to handle the fact that GoLand (when running on Windows) can't see my packages (in the WSL2 filesystem). – Shane Bishop Jun 24 '22 at 14:26
  • 2
    The go toolchain, and the `goimports` tool is perfectly fine referencing `cbor` while importing `"github.com/fxamacker/cbor/v2"`. This is something wrong with GoLand. – JimB Jun 24 '22 at 14:31
  • @JimB, this wasn't something wrong with GoLand, it was that I had not told GoLand what the `GOROOT` was in my WSL2 environment, so it couldn't resolve any of the dependencies, and find out that the import `"github.com/fxamacker/cbor/v2"` resolves to a package named `cbor`. – Shane Bishop Jun 24 '22 at 22:23
  • That stills seems strange, since you should never set GOROOT, and the go tool should report its location correctly. WSL has had a number of issues that thwart the go tool chain too, so maybe that has something to do with it. – JimB Jun 24 '22 at 23:13