rules_go: Why require that go_library() targets be named "go_default_library"?

[trea...@gmail.com]

The docs for rules_go say:

"""
For a library github.com/joe/project/lib, create lib/BUILD, containing a single library with the special name "go_default_library." Using this name tells Bazel to set up the files so it can be imported in .go files as (in this example) github.com/joe/project/lib.
"""
(from https://github.com/bazelbuild/rules_go)

Out of curiosity, when might I *not* want the files to be available for import into .go files? i.e., why are only targets named go_default_library made available for import?

Background:

I'm trying to construct some more complicated BUILD files to exploit some niche behaviors of Go, and the library naming restrictions are starting to bite.*

I've poked around at def.bzl in rules_go a bit. It looks like if one were to remove lines 170-171, I get what I need. However, I can't tell if this case was added for some specific reason that would then become broken.

If this is in support of some other feature, I totally understand. But if this behavior happened by accident or if it's no longer relevant, can we open up the naming for increased flexibility?

I've put together a repo that might make it easy to experiment with some BUILD target name variations. They also demonstrate the sort of thing I'm trying to do.
https://github.com/treaster/bazel_go_target_names

This file demonstrates some go_library() targets that are named in different ways.
https://github.com/treaster/bazel_go_target_names/blob/master/src/example.com/lib_target/BUILD

This file demonstrates some go_binary() targets that depend on those libraries.
https://github.com/treaster/bazel_go_target_names/blob/master/src/example.com/bin_target/BUILD

Thanks!!

-Mike

*Specifically, I want a BUILD file with two separate build targets for the Go package, where one target includes a few extra symbols for test-only purposes. This type of files-included-for-tests-only is supported by `go test`.

[Marc Fisher]

I think you are slightly misunderstanding what the go_default_library name is for. There is no problem with having multiple go_libraries with different names in the same Bazel package. The issue is what the import path is.

So if you have a lib/BUILD file with 

go_library(

    name = "go_default_library",

    srcs = ...

)

You can import it in a go file as:

import "go_prefix/lib"

However if you have the following in your BUILD files:

go_library(

    name = "a",

    ...

)

go_library(

    name = "b",

    ...

)

You would import them as:

import (

   "go_prefix/lib/a"

   "go_prefix/lib/b"

)

Marc

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/66cbe66a-bf3b-4fec-a6a9-848597d9963f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[trea...@gmail.com]

Ah, that clears up a lot. The docs only show an example for go_default_library, so it wasn't clear what the key difference was. Thanks for that explanation, Marc!

I think this design precludes the (admittedly narrow) use case I described above (selecting different source files for test vs non-test compilations of the same package) at least if I want the same code to be compatible with both bazel and "go build". To support this use case + tool compatibility, it would be useful to have multiple Bazel targets produce the same importpath.

What would the rules_go folks think about adding an optional "importpath" attribute to go_library()*? When the attribute isn't provided, keep the behavior we have today. When the attribute is provided, it overrides the importpath generated by _go_importpath().

I can provide a concrete example of my test-oriented use case if it would be helpful.

Thanks again,

-Mike

* and maybe other rule types