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

x/tools/cmd/goimports: weird behaviours - not importing and removing dependencies automatically #34518

Closed
brunoluiz opened this issue Sep 25, 2019 · 7 comments

Comments

@brunoluiz
Copy link

@brunoluiz brunoluiz commented Sep 25, 2019

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes, it does

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/brunoluiz/Library/Caches/go-build"
GOENV="/Users/brunoluiz/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/brunoluiz/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/brunoluiz/git/snapdiff/scheduler/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/46/73767m017_n8yfc849p52zpm0000gn/T/go-build095282659=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Using goimports -w file.go or through vim-go.

What did you expect to see?

Dependencies (external or internal) should be auto imported.

What did you see instead?

It doesn't auto-import packages from the same project/module, it doesn't fetch external packages and sometimes, even if I add import statements manually it scrapes it. Example: I am using strconv.itoa and even if I add strconv to imports statement, goimports removes it.

I thought initially it was a vim-go issue, but I've tried goimports -w file.go and it doesn't as expected.

Side note: if I run go get ..., it doesn't scrape the dependency.

@gopherbot gopherbot added this to the Unreleased milestone Sep 25, 2019
@gopherbot gopherbot added the Tools label Sep 25, 2019
@heschik
Copy link
Contributor

@heschik heschik commented Sep 25, 2019

I don't see anything suspicious in the provided go env output, and that's pretty much all there is to look at, so I have no idea what the problem is. Please provide a reproducer, or at least the output of goimports -v.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 26, 2019

@brunoluiz
Copy link
Author

@brunoluiz brunoluiz commented Sep 28, 2019

I've re-tried now and it ?seems it works? (using goimports -w), although vim-ale still struggles to find the external dependencies. Can gopls influence any of this?

@brunoluiz
Copy link
Author

@brunoluiz brunoluiz commented Oct 3, 2019

Okay, I did some extra digging today. Basically, I have this mono-repo with all services for this project. If goimports is ran from the root, it leads to these weird stuff I've mentioned -- the same apply if I open vim in this folder.

When goimports is executed from ./service folder, then it works. Perhaps, if it is not in the root, it can't resolve the go.mod files from the sub-folders?

@heschik
Copy link
Contributor

@heschik heschik commented Oct 3, 2019

Yes, goimports uses all the same rules as the go command itself for module mode. You have GO111MODULE unset, so it sounds like you were getting goimports in GOPATH mode when running in the parent dir. That wouldn't work well unless you actually had your GOPATH populated with all your dependencies.

@brunoluiz
Copy link
Author

@brunoluiz brunoluiz commented Oct 3, 2019

What would be the behaviour of goimports if my GO111MODULE was on instead of auto?

@heschik
Copy link
Contributor

@heschik heschik commented Oct 3, 2019

It will be able to find things that are in the module cache, but probably not much else, since it won't know what the import path of anything should be without knowing the module in use.

Closing, since there doesn't seem to be a bug here. For better or worse, most module-aware tools need to be run in the right working directory.

@heschik heschik closed this Oct 3, 2019
@golang golang locked and limited conversation to collaborators Oct 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.