Go (Gogland) support

[mwitkow]

We're currently moving our monorepo to Bazel, and the last dangling bit is:
https://github.com/bazelbuild/rules_go
We really enjoy Gogland and would love to have it nicely integrated with Bazel.

Is the custom skylark rule support in? If so, how would it work with the current Go plugin? @ignatov and @zolotov for context, as they're the main Golang Plugin developer.

[zolotov]

We're open to collaboration and we can provide any extension points that might be needed for integration.

As I can see, integrating Bazel with Gogland won't be a hard task, the only thing that Gogland should know from Bazel is where SDK and libraries can be found.

I took a look at the code. Unfortunately, we're going to get rid of using Java-specific libraries in Gogland and Go plugin, so looking for Go SDK- and GOPATH- prefixed libraries won't work anymore.

[mwitkow]

@ains and @yifanzz for context

[brendandouglas]

Custom skylark support is not in yet, but we're working on it.

We weren't planning to provide Gogland IDE support (see #37), but I believe JetBrains is planning to release a basically-equivalent IntelliJ UE plugin (similar to the PyCharm setup). Is that correct @zolotov?

If so, we're definitely interested in integrating with the Go plugin. Are there any plans for facet support in the Go plugin? (rather than requiring the project SDK be a Go SDK)

[zolotov]

Yes, there will be the Go plugin for IntelliJ Ultimate.

Why not support Gogland IDE? I didn't find the answer in #37. It's just the very same code as for plugin supporting. Please contact me if you have any technical issues on supporting different IDEs.

No, we're not going to introduce facets and the plugin doesn't require project SDK either. Instead, there will be a Gogland-specific project settings storage that will contain GOPATH and GOROOT settings.

[brendandouglas]

No technical problems supporting Gogland beyond the additional maintenance -- supporting only three products (IntelliJ Community, IntelliJ Ultimate, and CLion) significantly reduces our maintenance burden. So we try to encourage internal users to use IntelliJ UE rather than Webstorm, PyCharm, etc., in cases where the standalone IDE is a functional subset.

We'll certainly reconsider if there's demand for Gogland-specific support though.

[narqo]

Having no possibility to use bazel with Goglang is really sad. Currently, there is seems no any integrated build tools that could be used inside the IDE to build a complex project that doesn't feet into simple go build pipe.

[mwitkow]

What we do internally is we have a hack that code-generate a set of symlinks that we use as GOPATH out of bazel-bin and bazel-out. @ains can probably shed a little light here. However, this is a really really bad hack.

What's more, you can't even load the Bazel plugin into Gogland as it is complaining about lacking Java-specific dependencies. Would love to at least use the plugin for editing BUILD files.

[gfernandessc]

Are there more concrete plans for Go support on the plugin? The dependencies are not being imported properly in Intellij UE when using both the bazel plugin and the Go plugin.

[brendandouglas]

We have no concrete date for Go support, but it is something we'll definitely get to at some point.

[hsyed]

@brendandouglas could we get some documentation on how to configure the go support. I can't figure out how to set the goroot, and only code in the GOPATH is picked up (not vendored directories).

[brendandouglas]

Go support is extremely rudimentary at the moment. It's something we're currently working on.

When that's done, if it turns out there are manual set up steps required, we'll add them to the documentation.

[brendandouglas]

The latest release should have much-improved Go support, and GOPATH / import resolution should all be set up automatically as part of the Bazel sync action.

Closing this general issue, but please open separate issues for specific problems with Go support.

[promiseofcake]

I think the original issue is geared towards the fact that Gogland (now Goland) does now allow the installation of the IntelliJ plugin due to the IDE's missing Java dependencies.

[brendandouglas]

Yes, we don't build the plugin for Goland, but instead support using the Goland plugin in IntelliJ UE.

This has all the same features as Goland itself, but isn't specific to Go.

[brendandouglas]

The Bazel plugin should now be available for Goland, as of the latest release

[tdarci]

Very happy to have the Bazel plugin available for GoLand... though it fails to initialize. Getting "Bazel plugin dependencies are missing": "The JUnit plugin is disabled, but it's required for the Bazel plugin to function. Please enable the JUnit plugin and restart the IDE"

Unfortunately, there is no JUnit plugin for GoLand.

This is GoLand 2018.1.2 and Bazel Plugin 2018.01.02.0.1. On Mac that also has IntelliJ IDEA Ultimate installed.

Failure seems to be in initComponent() here: https://github.com/bazelbuild/intellij/blob/d5e4e5073473a4a66d869d40743a08f8846063d5/java/src/com/google/idea/blaze/java/plugin/JUnitPluginDependencyWarning.java

Any info/guidance much appreciated.

thanks,
td

[promiseofcake]

@tdarci, I think it's currently only supported for the 2017.x releases as of the latest plugin release.

[mennanov]

@mwitkow , @ains you mentioned that

What we do internally is we have a hack that code-generate a set of symlinks that we use as GOPATH out of bazel-bin and bazel-out. @ains can probably shed a little light here. However, this is a really really bad hack.

Could you, please, share the details?

Unfortunately i could not make the plugin work with the most recent Intellij or GoLand. It only works for me in Intellij 2017.3 but its Go integration is not as nice as i expected:

so it fails to resolve local imports (and also some non-local), however everything builds and runs (tests) fine in Bazel.

[chaoren]

The open source rules_go implementation has different providers from what blaze has internally, and we can't access them without a hard dependency on rules_go from our aspect. Until that issue is resolved, we won't be able to resolve test and protobuf sources.

[mennanov]

Given the popularity of rules_go externally would it make sense to add them to //third_party/golang and make Blaze be aware of it?

[chaoren]

It needs to be exactly the same copy that the user is loading into their project. We can't ask all of our users to load rules_go.

[mennanov]

@chaoren , is there any workaround for this problem?
Can i manually add the locations of the generated *.pb.go files to $GOPATH in GoLand settings? If yes, how can i do that properly?

As i've tried different approaches and neither of them worked.
For example consider the following code:

import "github.com/mennanov/scalemate/accounts/proto/accounts"

The generated *.pb.go files (produced by the go_proto_library rule) are located here:

/Users/renat/go-paths [renat@renat] [14:19]
> tree /Users/renat/go/src/github.com/mennanov/scalemate/bazel-bin/accounts/proto/darwin_amd64_stripped/accounts_go_proto%/github.com
/Users/renat/go/src/github.com/mennanov/scalemate/bazel-bin/accounts/proto/darwin_amd64_stripped/accounts_go_proto%/github.com
└── mennanov
    └── scalemate
        └── accounts
            └── proto
                ├── accounts
                │   ├── accounts.pb.go
                │   └── accounts.validator.pb.go
                └── accounts.a

I created a separate folder to mimic a GOPATH and added it to the GoLand GOPATH settings:

/Users/renat/go-paths [renat@renat] [14:19]
> tree
.
└── scalemate-accounts-proto
    ├── pkg
    └── src
        └── github.com -> /Users/renat/go/src/github.com/mennanov/scalemate/bazel-bin/accounts/proto/darwin_amd64_stripped/accounts_go_proto%/github.com

But GoLand is still unable to resolve this import.

[mennanov]

$GOPATH seems to be ignored by GoLand when the Bazel intellij plugin is activated.

I've finally come up with an ugly hack: created symlinks in the same directory where the .proto files are to the generated *.pb.go files and added a separate go_library rule:

# gazelle:exclude accounts.pb.go
# gazelle:exclude accounts.validator.pb.go
go_library(
    name = "go_proto_hack",
    srcs = [
        "accounts.pb.go",
        "accounts.validator.pb.go"
    ],
    importpath = "github.com/mennanov/scalemate/accounts/accounts_proto",
    visibility = ["//visibility:public"],
    deps = [
        "//shared/proto:go_default_library",
        "@org_golang_google_grpc//:go_default_library",
        "@com_github_golang_protobuf//proto:go_default_library",
        "@com_github_mwitkow_go_proto_validators//:go_default_library",
        "@io_bazel_rules_go//proto/wkt:empty_go_proto",
        "@io_bazel_rules_go//proto/wkt:field_mask_go_proto",
        "@io_bazel_rules_go//proto/wkt:timestamp_go_proto",
        "@org_golang_x_net//context:go_default_library",
    ],
)

Without having this go_library rule I got build constraints exclude all Go files in '' error message at the import path even though the files were physically presented in this directory.

UPD: actually, there is a better solution #194 (comment)