go_proto_library failure using rules_go 0.5.3 and bazel 0.5.3

[razvanm]

I'm trying to use the go_proto_library using rules_go 0.5.3 and bazel 0.5.3 and I'm hitting problems.

The error looks like this:

$ bazel --bazelrc=/dev/null build dummy:go_default_library 
ERROR: /tmp/dummy-proto/dummy/BUILD:3:1: in go_library rule //dummy:go_default_library: 
Traceback (most recent call last):
	File "/tmp/dummy-proto/dummy/BUILD", line 3
		go_library(name = 'go_default_library')
	File "/home/razvanm/.cache/bazel/_bazel_razvanm/d7dfc79fb60f41163c5f709a2b85d61b/external/io_bazel_rules_go/go/private/library.bzl", line 143, in _go_library_impl
		emit_library_actions(ctx, sources = depset(ctx.files.sr...), <4 more arguments>)
	File "/home/razvanm/.cache/bazel/_bazel_razvanm/d7dfc79fb60f41163c5f709a2b85d61b/external/io_bazel_rules_go/go/private/library.bzl", line 57, in emit_library_actions
		ctx.new_file(("~lib~/" + lib_name))
dummy/~lib~/./dummy.a
ERROR: Analysis of target '//dummy:go_default_library' failed; build aborted
INFO: Elapsed time: 9.349s
FAILED: Build did NOT complete successfully (22 packages loaded)
$

Note that the rule that generas the .pb.go is happy:

$ bazel --bazelrc=/dev/null build dummy:go_default_library_protos
INFO: Analysed target //dummy:go_default_library_protos (0 packages loaded).
INFO: Found 1 target...
Target //dummy:go_default_library_protos up-to-date:
  bazel-genfiles/dummy/dummy.pb.go
INFO: Elapsed time: 38.403s, Critical Path: 7.48s
INFO: Build completed successfully, 204 total actions
$

In case is helps, I noticed two more things:

• I get the same error using a local_repository for io_bazel_rules_go (that's how I initially bump into this problem)
• the error doesn't happen when placing the ./dummy/BUILD and ./dummy/dummy.proto in the rules_go 0.5.3 workspace.

The files to reproduce the above error (I get the same error on both Linux and macOS):

$ find . -type f
./WORKSPACE
./BUILD
./dummy/BUILD
./dummy/dummy.proto
$

WORKSPACE:

# workspace(name = "dummy")

git_repository(
    name = "io_bazel_rules_go",
    remote = "https://github.com/bazelbuild/rules_go.git",
    tag = "0.5.3",
)

load("@io_bazel_rules_go//go:def.bzl", "go_repositories")
go_repositories()

load("@io_bazel_rules_go//proto:go_proto_library.bzl", "go_proto_repositories")
go_proto_repositories()

BUILD:

load("@io_bazel_rules_go//go:def.bzl", "gazelle", "go_prefix")
load("@io_bazel_rules_go//proto:go_proto_library.bzl", "go_google_protobuf")

go_prefix(".")
go_google_protobuf()

dummy/BUILD:

load("@io_bazel_rules_go//proto:go_proto_library.bzl", "go_proto_library")

go_proto_library(
    name = "go_default_library",
    srcs = ["dummy.proto"],
)

dummy/dummy.proto:

syntax = "proto3";

package dummy;

message Dummy {
  string dummy = 1;
}

$ bazel version
.......
Build label: 0.5.3
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Jul 28 08:34:59 2017 (1501230899)
Build timestamp: 1501230899
Build timestamp as int: 1501230899
$

[ianthehat]

go_prefix is supposed to be a fully qualified import path, "." is not valid. Not sure if that's what is causing the problem or not.

[razvanm]

You are right, that was indeed the issue. go_prefix("") solved the problem. Thanks for the help! :-) Would have been nice if the error message was a bit more explicit about what is wrong.

$ cat BUILD 
load("@io_bazel_rules_go//go:def.bzl", "gazelle", "go_prefix")
load("@io_bazel_rules_go//proto:go_proto_library.bzl", "go_google_protobuf")

go_prefix("")
go_google_protobuf()
$ bazel --bazelrc=/dev/null build dummy:go_default_library 
INFO: Analysed target //dummy:go_default_library (0 packages loaded).
INFO: Found 1 target...
Target //dummy:go_default_library up-to-date:
  bazel-bin/dummy/~lib~/dummy.a
INFO: Elapsed time: 0.062s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action
$ 

[ianthehat]

I agree that a nicer message would be good, but I recently proposed that we delete go_prefix totally, (see #721) and Jay has already started working on it (see #733), it's already at the point where for this use case you would not need a go_prefix at all, so I would prefer not to spend time improving it.

I don't think the error messages from explicit but incorrect importpath settings will be as obtuse or hard to work out why they happened.

Please re-open if you disagree with any of this!