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.

Sign up for GitHub

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

Jump to bottom

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

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

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

brunoluiz opened this issue Sep 25, 2019 · 7 comments
Labels
FrozenDueToAge Tools This label describes issues relating to any tools in the x/tools repository. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Unreleased

Comments

@brunoluiz
Copy link

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 This label describes issues relating to any tools in the x/tools repository. label Sep 25, 2019
@heschi
Copy link
Contributor

heschi 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
Contributor

bcmills commented Sep 26, 2019

CC @matloob

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Sep 26, 2019
@brunoluiz
Copy link
Author

brunoluiz commented Sep 28, 2019 •
edited

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

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?

@heschi
Copy link
Contributor

heschi 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

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

@heschi
Copy link
Contributor

heschi 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.

@heschi heschi closed this as completed 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.
Assignees
No one assigned
Labels
FrozenDueToAge Tools This label describes issues relating to any tools in the x/tools repository. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@brunoluiz @bcmills @gopherbot @heschi