I am trying to browse code for gVisor with VScode.
However, unlike other Go projects, gVisor is built with bazel, and the source code is not located under $GOROOT or $GOPATH. Maybe this prevents gVisor packages from being searched by VSCode go extension. Go-to-definition is not working in most cases, except for cases where the definition can be found under the same directory.
How can I setup VSCode with bazel Go projects? Especially gVisor. Thanks!
The linked gVisor rule now proxies a more canonical implementation
This setup worked for me:
In your workspace's root BUILD file you can add the following build rule
# in BUILD.bazel
load("#io_bazel_rules_go//go:def.bzl", "go_path")
go_path(
name = "gopath",
mode = "link",
deps = [
"//my/binary/here",
"//any/other/binaries/you/want/linked",
],
)
(if you don't yet have a gazelle import for the bazelbuild/go_rules, you would need to import it for bazel)
# in WORKSPACE
http_archive(
name = "io_bazel_rules_go",
sha256 = "8e968b5fcea1d2d64071872b12737bbb5514524ee5f0a4f54f5920266c261acb",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.28.0/rules_go-v0.28.0.zip",
"https://github.com/bazelbuild/rules_go/releases/download/v0.28.0/rules_go-v0.28.0.zip",
],
)
Build this command to create a symlinked folder in your blaze-out at bazel-bin/gopath that contains links to each of your dependencies. You'll have to do this any time you add a new dependency. You will see a line for each symlink created.
bazel build :gopath
(assuming you're using VSCode with the Golang extension) Set your workspace settings for the go extension to point to this gopath. Note you'll need to have it be a worspace trusted extension in order for this to work.
// In .vscode/settings.json
{
"go.gopath": "/YOUR ABSOLUTE PATH TO YOUR WORKSPACE//bazel-bin/gopath"
}
Restart VSCode
Enjoy!
NOTE: if you have a go.mod file in your root dir, this will not work.
gVisor recently added a gopath BUILD rule that creates a canonical GOPATH tree from the source.
You may be able to use that the edit more effectively from VScode.
Related
I have a .proto protobuf definition file in a dir and I'm building a go library from it with Bazel like so (BUILD.bazel file below generated using gazelle):
load("#rules_proto//proto:defs.bzl", "proto_library")
load("#io_bazel_rules_go//go:def.bzl", "go_library")
load("#io_bazel_rules_go//proto:def.bzl", "go_proto_library")
proto_library(
name = "events_proto",
srcs = ["events.proto"],
visibility = ["//visibility:public"],
deps = ["#com_google_protobuf//:timestamp_proto"],
)
go_proto_library(
name = "proto_go_proto",
importpath = "github.com/acme/icoyote/proto",
proto = ":events_proto",
visibility = ["//visibility:public"],
)
go_library(
name = "proto",
embed = [":proto_go_proto"],
importpath = "github.com/acme/icoyote/proto",
visibility = ["//visibility:public"],
)
Some other code depends on //icoyote/proto:proto, and when I run go mod tidy in my module, it complains that it can't find the package github.com/acme/icoyote/proto:
go: finding module for package github.com/acme/icoyote/proto
github.com/acme/icoyote/cmd/icoyote imports
github.com/acme/icoyote/proto: no matching versions for query "latest"
Any IDE that doesn't have Bazel integration (e.g. VSCode, GoLand/IntelliJ without the Bazel plugin) complains as well
What do I do?
This is happening of course because because Bazel does generate .go files using protoc under the covers for the go_proto_library rule in the BUILD file, but only writes them out to a temp dir under bazel-bin to be used by the go_library rule, and go mod tidy doesn't seem look into bazel-bin (probably because it's a symlink but also if it did, the path of those files relative to the location of go.mod is all wrong)
One option is to manually generate the go files by calling protoc on your own, and remove the proto_library and go_proto_library rules in the BUILD file, then change the go_library rule to build your generated files. This is suboptimal because you have to manually rerun protoc every time you make changes to the .proto file (and if you put it into a //go:generate directive, you have to rerun go generate).
Instead, we can do the following:
Add a file empty.go to the dir that contains the .proto file. It should look like this:
package proto
Then tell gazelle to ignore empty.go (so it doesn't try to add a go_library rule to the BUILD file when you run gazelle --fix). We do that by adding the following to the BUILD file:
# gazelle:exclude empty.go
That's enough to make go mod tidy shut up.
This will also make the IDE stop complaining about the import, although you'll still get errors when referring to anything that's supposed to be in that package. If you don't want to abandon your IDE for an excellent GoLand or IntelliJ IDEA with a Bazel plugin, you might have to resort to the manual protoc method. Perhaps there's a way to create a symlink to wherever Bazel writes out the generated .go files under bazel-bin and force go mod tidy to follow it, but I haven't tried that. If you do and it works, do share!
I'm new in GO and has got stuck in environment configuration for hours.
I succeeded to run some test projects, but when I tried to import my custom local packages (say xxx), the "go run" command failed, logging that:
*test/main/main.go:6:2: package test/xxx is not in GOROOT (/usr/local/go/src/test/xxx)*
It is strange that GOPATH seems to be ignored when importing local packages on my ubuntu computer.
go version is go1.16.5 linux/amd64
GOPATH is set using export GOPATH="$HOME/GoProjects"
GOROOT is set using export GOPATH="/usr/local/go"
GoMod is "on" using go env -w GO111MODULE=on
After editing project's .go files, command "go mod init" and "go mod tidy" are typed in the root folder of the project ($GOPATH/src/test), and the project file structure looks like:
/src
/.vscode
-launch.json
/gitbub.com
/test
/main
-main.go (here: import "test/xxx")
/xxx
-xxx.go (here: package xxx)
-go.mod (almost empty - line 1: module test
line 2:
line 3: go 1.16 )
What should I do to fix this problem?
Assuming (not clear from your post) this entire tree is under your $HOME/GoProjects. When using modules; don't put your project inside GOPATH as mixing both GOPATH and modules only leads to problems.
First, set $GOPATH to something like $HOME/go which you can use to go get various tools you want to use across projects (such as e.g. dlv debugger and so on) but do not put your projects in there.
When starting a new project put it outside $GOPATH to $HOME/GoProjects/test (you can retain project layout you have under src but you do not need src there):
GoProjects
/test
/main
-main.go
/xxx
-xxx.go
In project directory (here test) run go mod init NAME where NAME is name of your module. Do not use just test but fully qualified name which will namespace your project to your "domain" (e.g. github.com/yourusername/test). That name will then be used when importing packages from your module. So in main.go you will import xxx package (needs to have package xxx) like this:
import "github.com/yourusername/test/xxx"
See more info about modules here: https://blog.golang.org/using-go-modules
First, stop worrying about GOPATH. That is old stuff, and you don't need to do it any more. Then, make a folder somewhere test (doesn't need to be anything to do with GOPATH, just put in current directory, or wherever you want). Then make test/xxx. Then make test/xxx/xxx.go:
package xxx
const X = 1
Then make folder test/main. Then make test/main/main.go:
package main
import "test/xxx"
func main() {
println(xxx.X)
}
Then go back to test, and do go mod init test. Then go back to test/main,
and do go build. Done.
I am doing some light hacking on the rclone project, and I'm somewhat new to go. I have cloned the repository in my home directory, /home/poundifdef/rclone.
When I look at the file, rclone.go, in the top-level directory, I see the following import statement:
package main
import (
_ "github.com/ncw/rclone/backend/all"
"github.com/ncw/rclone/cmd"
_ "github.com/ncw/rclone/cmd/all"
)
My question is this: nowhere in this code, as far as I can tell, do we specify that the github.com/ncs/rclone/* packages are supposed to refer to the local versions of these directories. Nowhere in my filesystem have I used a directory called github.com/ncw. And yet, running go run rclone.go is able to execute this code.
Where is the path github.com/ncw/rclone being mapped to my local directory, given these packages, as named, do not exist?
github.com/ncw/rclone is a module, because it has a file named go.mod at the repository root. Since you have $GOPATH unset, the experimental module feature is enabled.
Where modules are placed in your filesystem is irrelevant. when constructing import paths, all directory names in the module are appended to the module name. The module name is defined in the first line of go.mod, here "github.com/ncw/rclone". So the package in ./cmd has the import path github.com/ncw/rclone/cmd.
Commands such as go build, go install, go test, etc. download all other required packages automatically to $HOME/go/pkg/mod, unless the -mod=vendor flag is specified, in which case the sources in vendor are used.
Golang has an internal mechanism to resolve import path.
This mechanism relies on the existence of several variables on your computer, GOROOT, GOPATH and for old releases GO15VENDOREXPERIMENT.
When the compiler meet a package path, it performs a look up with those paths
GOROOT/src/[import path]
GOPATH/src/[import path]
cwd/vendor/[import path]
The longest path wins and is selected for further processing.
GOROOT is the path to the stdlib.
GOPATH is the path to your local workspace.
For all the details https://go.googlesource.com/proposal/+/master/design/25719-go15vendor.md
This all depends on the setup of your computer, so carefully check go env output.
I'm trying to understand how to organize my golang project using go1.11 modules. I tried several options, but none of them worked.
I have some code in the main package under the application folder and a local package that the main package uses.
$GOPATH
+ src
+ application/
+ main/
+ main.go
+ otherFileUnderMainPackage.go
+ aLocalPackage/
+ someCode.go
+ someCode_test.go
+ someMoreCode.go
+ someMoreCode_test.go
Files in the main package, imports ../aLocalPackage. When I compile by go build main/*.go it's working.
Then, I ran go mod init application: V.0.9.9 and got the go.mod file, but the build always fails. I always get error about not finding the local package: build application:V0.9.9/main: cannot find module for path _/.../src/application/aLocalPackage. I also tried to place the local package right under src/, place it under main/ etc. but none of these methods worked for me.
What is the way to use modules and local packages?
Thanks.
Relative import paths are not supported in module mode. You will need to update your import statements to use a full (absolute) import path.
You should also choose a module name other than application. Your module path should generally begin with a URL prefix that you control — either your own domain name, or a unique path such as github.com/$USER/$REPO.
I had some problems working with local packages myself.
There are two tricks to make it work:
you run "go build" in the package directory
This compiles the package and places it in the build cache.
This link about code organisation in go explains more.
You can identify where the cache is using:
>go env GOCACHE
/home/<user>/.cache/go-build
Import using a path relative to the project
I puzzled loads over what the correct import path was and finally discovered that go doc or go list will tell you.
>go doc
package docs // import "tools/src/hello/docs"
>go list
tools/src/hello/docs
For example. I have a hello world API project and was using swaggo to generate documentation which it does in a docs sub-directory.
To use it I add an import:
_ "tools/src/hello/docs"
For my case the _ is important as docs is not used directly but we its init() function to be invoked.
Now in hello/main.go I can add "tools/src/hello/docs" and it will import the correct package.
The path is relative to the location of go.mod if you have one.
I have tools/ here as I have a go.mod declaring "modules tools".
Modules are a different kettle of fish - see https://github.com/golang/go/wiki/Modules.
Recent versions of go (1.11 and later) can create a go.mod file which you may use to fix the version of a module that is used and avoid go's crazy default behaviour of just downloading the latest version of any package you import.
I have written a blogpost on how to start your first Go project using modules.
https://marcofranssen.nl/start-on-your-first-golang-project/
In general it boils down to just create a new folder somewhere on your system (doesn't have to be in GOPATH).
mkdir my-project
cd my-project
go mod init github.com/you-user/my-project
This will create the go.mod file. Now you can simply create your project layout and start building whatever you like.
Maybe one of my other blogs can inspire you a bit more on how to do things.
https://marcofranssen.nl/categories/software-development/golang/
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.