Is it possible to do the equivalent of go build ./... in GoLand, so I can see all the errors in the IDE in one go? I have modified some widely used structs and I want to find all the places I need to change.
I have tried a package build at the top of my tree but that "succeeds" very quickly whereas build ./... in the same directory fails as expected.
I also tried a directory build with ./... as a tool argument but that gives an error
can't load package: package -o: cannot find package "-o" in any of:
which I assume is because whatever GoLand is putting around the configuration is not compatible with that argument.
As #nestor-sokil, mentioned above, if you perform the refactoring operations via the IDE tools, Refactor | Refactor This..., then the IDE manages all the changes automatically for you. If you do find places where this doesn't happen or a refactoring tool is missing, you can open an issue on the issue tracker.
That being said, you can follow the instructions below to configure the IDE to run go build ./... for you. The caveat is that it may show problems that are not normally encountered in operations as the command is unaware of build tags, multiple main() function containing files in the same directory, and so on.
You can create an external tool via Settings/Preferences | Tools | External Tools and configure like this:
You can then go to Settings/Preferences | Keymap and search for the name of the tool and assign it a shortcut to execute it more conveniently.
Related
Not having previous knowledge about creating a project from zero within terminal, I've created a folder, cd into of it then run go mod init my_project_name which created a go.mod file for me, then I've created main.go file which built just ok.
Then I created a folder and add a go file inside with package name (being same with directory) and create a struct inside of it. Next I tried to import that package in main package but when I try to build on terminal it gave me this error
go: cannot determine module path for source directory /Users/berkcan/workspace/go/my_project_name (outside GOPATH, module path must be specified)
After googling and not being able to find a solution to my problem, I've imported project to beloved Intellij IDE and I enabled Go modules integration then everything worked flawlessly. First I thought IDE doing some magic inside while building project but even when I try go build command in terminal, it built. But I cant see difference in project structure or a new line in go.mod file.
So what happened, what did Intellij IDE did when I ticked go module integration box and what I can do enable it on terminal without Intellij IDE ?
here is the photo of option in IDE when ticked
IntelliJ IDEA plus Go plugin or GoLand under the hood has two modes to get the information about your packages (simplified):
GOPATH. IDEA scans your $GOPATH directory to build internal indexes of your packages and provides code completion, resolving, etc.
Go Modules. IDEA executes go list -m -json to resolve your dependencies and scans your $GOPATH/pkg/mod directory (default value of GOMODCACHE) for the packages. If they don't exist, IDEA executes go mod download. After these operations, the IDE provides all built-in features like code completion, navigation and so on.
Both modes don't change your Go or environment variables as well as behavior in the terminal. When you check Enable Go Modules integration option in the settings, the IDE just switches the mode from scan $GOPATH to execute go list and resolve your dependencies from the Go Modules cache.
To summarize, IntelliJ IDEA doesn't do any magic. I suppose it relates to your custom Go environment variables inside the terminal, especially GO111MODULE and if you didn't pass these variables to the GUI apps (e.g. you have specified it in .zshrc file and run the IDE via Desktop entry instead of the terminal), IntelliJ IDEA doesn't inherit them. You can compare go env output inside your local terminal and built-in inside the IDE (View | Tool Windows | Terminal) and find differences.
I'm trying through kubebuilder tutorial, and just imported existing project to GoLand.
Workthrough with kubebuilder auto-generated scaffold codes, and auto-downloaded pkgs with go mod for me. I had no problem when I was working with commandline environment, but turns out, after opening the project with GoLand, IDE is failing to resolve imported package names, which means it is failing to detect - or link - packages installed by go mod.
I enabled go mod(with vendoring) and dep both from IDE preferences, set GOPATH and Go runtime properly, but the error keeps to appear.
I don't know why I'm getting this error, and how to solve it.
+) Working Directory is $GOPATH/src/example, all the logics and settings are placed in the directory. Installed dependencies are placed under $GOPATH/pkg/mod.
I enabled go mod(with vendoring) and dep both from IDE preferences, set GOPATH and GOROOT properly, but the error keeps to appear.
Let's assume that you have the following setup on your machine:
Go is installed under /usr/lib/go
GOPATH is set to /home/florin/go
the KubeBuilder project named demobuilder is created under /home/florin/projects/demobuilder. I recommend this as opposed to using GOPATH, as you do, for Go Modules projects because they behave in a different way while in GOPATH.
First, make sure that you have GoLand 2019.3.1 or newer.
Then, after creating the demobuilder project, start GoLand, then click on the Open Project button.
When the project is opened, if you have not configured yet, the IDE will ask you for the Go SDK configuration, aka GOROOT. It will be a yellow bar at the top of the editor. Click on the link on the right side to configure it. You can select the local installation and point it to /usr/local/go. If you don't have Go installed, you can also download it in a directory of your choice.
Then, the IDE should automatically notice that the project is a Go Modules based project and enable the support for them. If it's not, then go to Settings/Preferences | Go | Go Modules and enable that. DO NOT enable both Go Modules and dep support at the same time. If you did that, disable the dep integration and try again.
You can see all of these in the help page.
Is Go modules integration enabled via File | Settings | Languages & Frameworks | Go | Go Modules
Most of the golang tools like golint, gopkgs etc are installed like libraries with go get for instance, go get -v github.com/golang/lint/golint or go get -v github.com/tpng/gopkgs. I wonder why these are not just binaries that run through the source code, like go fmt, for example?
Since I work on multiple Go projects at the same time, I prefer having different GOPATH for different projects and so I am having to install these tools into every single project so that I can lint or have auto completions.
Am I doing something wrong or is there a way to install these tools globally and then just use them in multiple projects? How do people handling multiple projects manage this?
EDIT:
I am not asking about vendoring of libraries or about projects using different versions of Go at the same time. My question is about having to install tools like lint and gopkgs into every GOPATH, why they were designed to be treated like libraries instead of being provided as a global binary like go fmt which then could've been used in multiple projects, just like we use go fmt
so I am having to install these tools into every single project so that I can lint or have auto completions.
No you don't: see how Visual Studio Code does it through its Microsoft vscode-go plugin (since its 0.6.53 version, January 2017).
New setting go.toolsGopath, for providing an alternate location to install all the Go tools that the extension depends on, if you don't want them cluttering your GOPATH.
See PR 351 and PR 737
The tools installed in that one common `` folder are:
'gocode': 'github.com/nsf/gocode',
'gopkgs': 'github.com/tpng/gopkgs',
'go-outline': 'github.com/ramya-rao-a/go-outline',
'go-symbols': 'github.com/acroca/go-symbols',
'guru': 'golang.org/x/tools/cmd/guru',
'gorename': 'golang.org/x/tools/cmd/gorename',
'gomodifytags': 'github.com/fatih/gomodifytags',
'impl': 'github.com/josharian/impl'
(and a few others, around godoc, goimports or goreturns, dlv, ...),
That means your GOPATH is composed of:
your project-specific workspace folder
a global go.toolsGopath workspace folder dedicated to tools used by all projects.
The tools are installed/updated in the bin/ subfolder of that latter workspace.
You can do that manually too (without Visual Studio Code): simply set GOPATH to that global tools folder whenever you want to install/update the tools.
Then reset GOPATH to my/project/dedicated/workspace;/tools/workspace, and add both bin/ subfolders to your $PATH/%PATH%.
The OP Nithin adds in the comments:
these tools can be compiled to binaries and if those binaries are available in $PATH, most editors, as far as I tested (based on your post), both vscode and atom (go-plus) will work and wont go get them again.
It is easier to update if they are treated like libraries. (I mean go get)
New Go programmers often don't know or get confused what the fundamental go build command does.
What do exactly the go build and go install commands build and where do they put the result/output?
What the go command does depends on whether we run it for a "normal" package or for the special "main" package.
For packages
go build builds your package then discards the results.
go install builds then installs the package in your $GOPATH/pkg directory.
For commands (package main)
go build builds the command and leaves the result in the current working directory.
go install builds the command in a temporary directory then moves it to $GOPATH/bin.
What to pass to go build?
You may pass packages to go build, packages you want to build. You may also pass a list of .go files from a single directory, which is then treated as the list of source files specifying a single package.
If no packages (import paths) are provided, the build is applied on the current directory.
An import path may contain one or more "..." wildcards (in which case it is a pattern). ... can match any string, e.g. net/... matches the net package and packages being in any of its subfolders. The command
go build ./...
often used to build the package in the current folder and all packages recursing down. This command issued in a project root builds the complete project.
For more about specifying packages, run go help packages.
Regarding modules
Preliminary support for Go modules was introduced in Go 1.11, and modules became default starting with Go 1.13. When the go tool is run from a folder which contains a go.mod file (or one of the parents of the current folder), the go tool runs in module-aware mode (the legacy mode is called GOPATH mode).
In module-aware mode, GOPATH no longer defines the meaning of imports
during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
and installed commands (in GOPATH/bin, unless GOBIN is set).
When building modules, what is built is specified by the build list. The build list initially contains only the main module (the module containing the directory where the go command is run), and the dependencies of the main module are added to the build list, recursively (dependencies of dependencies are also added).
For more info, run go help modules.
Basically you can use go build as a check that the packages can be built (along with their dependencies) while go install also (permanently) installs the results in the proper folders of your $GOPATH.
go build will silently terminate if everything is OK, and will give you error messages if the packages cannot be built/compiled.
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
For a start, read the official How to Write Go Code page.
More information about the go tool: Command go
You can also get more help by running the following command:
go help build
It is also worth noting that starting with Go 1.5 go install also removes executables created by go build (source):
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind...
To complete the list, go run compiles your application into a temporary folder, and starts that executable binary. When the app exits, it properly cleans up the temporary files.
Question inspired by Dave Cheney's What does go build build?
For package:
go build: builds your package then discards the results
That won't be true after Go 1.10 (Q1 2018), thank to CL 68116 and CL 75473. See this thread, that I reference here.
What do exactly the go build and go install commands build
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
Actually... go install will change also with Go 1.10, in addition of the new cache:
The "go install" command no longer installs dependencies of the named packages (CL 75850).
If you run "go install foo", the only thing installed is foo.
Before, it varied. If dependencies were out-of-date, "go install" also installed any dependencies.
The implicit installation of dependencies during "go install" caused a lot of confusion and headaches for users, but it was previously necessary to enable incremental builds.
Not anymore.
We think that the new "install what I said" semantics will be much more understandable, especially since it's clear from bug reports that many users already expected them.
To force installation of dependencies during "go install", use the new "go install -i", by analogy with "go build -i" and "go test -i".
The fact that "go install" used to install any rebuilt dependencies caused confusion most often in conjunction with -a, which means "force rebuild of all dependencies".
Now, "go install -a myprog" will force a complete rebuild of all dependencies of myprog, as well as myprog itself, but only myprog will get installed. (All the rebuilt dependencies will still be saved in the build cache, of course.)
Making this case work more understandably is especially important in conjunction with the new content-based staleness analysis, because it sees good reasons to rebuild dependencies more often than before, which would have increased the amount of "why did my dependencies get installed" confusion.
For example, if you run "go install -gcflags=-N myprog", that installs a myprog built with no compiler optimizations, but it no longer also reinstalls the packages myprog uses from the standard library without compiler optimizations.
New Go programmers often don't know or get confused what the fundamental go build command does.
What do exactly the go build and go install commands build and where do they put the result/output?
What the go command does depends on whether we run it for a "normal" package or for the special "main" package.
For packages
go build builds your package then discards the results.
go install builds then installs the package in your $GOPATH/pkg directory.
For commands (package main)
go build builds the command and leaves the result in the current working directory.
go install builds the command in a temporary directory then moves it to $GOPATH/bin.
What to pass to go build?
You may pass packages to go build, packages you want to build. You may also pass a list of .go files from a single directory, which is then treated as the list of source files specifying a single package.
If no packages (import paths) are provided, the build is applied on the current directory.
An import path may contain one or more "..." wildcards (in which case it is a pattern). ... can match any string, e.g. net/... matches the net package and packages being in any of its subfolders. The command
go build ./...
often used to build the package in the current folder and all packages recursing down. This command issued in a project root builds the complete project.
For more about specifying packages, run go help packages.
Regarding modules
Preliminary support for Go modules was introduced in Go 1.11, and modules became default starting with Go 1.13. When the go tool is run from a folder which contains a go.mod file (or one of the parents of the current folder), the go tool runs in module-aware mode (the legacy mode is called GOPATH mode).
In module-aware mode, GOPATH no longer defines the meaning of imports
during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
and installed commands (in GOPATH/bin, unless GOBIN is set).
When building modules, what is built is specified by the build list. The build list initially contains only the main module (the module containing the directory where the go command is run), and the dependencies of the main module are added to the build list, recursively (dependencies of dependencies are also added).
For more info, run go help modules.
Basically you can use go build as a check that the packages can be built (along with their dependencies) while go install also (permanently) installs the results in the proper folders of your $GOPATH.
go build will silently terminate if everything is OK, and will give you error messages if the packages cannot be built/compiled.
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
For a start, read the official How to Write Go Code page.
More information about the go tool: Command go
You can also get more help by running the following command:
go help build
It is also worth noting that starting with Go 1.5 go install also removes executables created by go build (source):
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind...
To complete the list, go run compiles your application into a temporary folder, and starts that executable binary. When the app exits, it properly cleans up the temporary files.
Question inspired by Dave Cheney's What does go build build?
For package:
go build: builds your package then discards the results
That won't be true after Go 1.10 (Q1 2018), thank to CL 68116 and CL 75473. See this thread, that I reference here.
What do exactly the go build and go install commands build
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
Actually... go install will change also with Go 1.10, in addition of the new cache:
The "go install" command no longer installs dependencies of the named packages (CL 75850).
If you run "go install foo", the only thing installed is foo.
Before, it varied. If dependencies were out-of-date, "go install" also installed any dependencies.
The implicit installation of dependencies during "go install" caused a lot of confusion and headaches for users, but it was previously necessary to enable incremental builds.
Not anymore.
We think that the new "install what I said" semantics will be much more understandable, especially since it's clear from bug reports that many users already expected them.
To force installation of dependencies during "go install", use the new "go install -i", by analogy with "go build -i" and "go test -i".
The fact that "go install" used to install any rebuilt dependencies caused confusion most often in conjunction with -a, which means "force rebuild of all dependencies".
Now, "go install -a myprog" will force a complete rebuild of all dependencies of myprog, as well as myprog itself, but only myprog will get installed. (All the rebuilt dependencies will still be saved in the build cache, of course.)
Making this case work more understandably is especially important in conjunction with the new content-based staleness analysis, because it sees good reasons to rebuild dependencies more often than before, which would have increased the amount of "why did my dependencies get installed" confusion.
For example, if you run "go install -gcflags=-N myprog", that installs a myprog built with no compiler optimizations, but it no longer also reinstalls the packages myprog uses from the standard library without compiler optimizations.