bazelbuild / bazel-gazelle Goto Github PK

Gazelle is a Bazel build file generator for Bazel projects. It natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.

License: Apache License 2.0

Go 80.26% Shell 0.37% Starlark 19.37%

bazel-gazelle's Introduction

Gazelle build file generator

Gazelle is a build file generator for Bazel projects. It can create new BUILD.bazel files for a project that follows language conventions, and it can update existing build files to include new sources, dependencies, and options. Gazelle natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.

Gazelle may be run by Bazel using the gazelle rule, or it may be installed and run as a command line tool. Gazelle can also generate build files for external repositories as part of the go_repository rule.

Gazelle is under active development. Its interface and the rules it generates may change. Gazelle is not an official Google product.

Mailing list: bazel-go-discuss

Slack: #go on Bazel Slack, #bazel on Go Slack

rules_go and Gazelle are getting community maintainers! If you are a regular user of either project and are interested in helping out with development, code reviews, and issue triage, please drop by our Slack channels (linked above) and say hello!

Contents

See also:

Supported languages

Gazelle can generate Bazel BUILD files for many languages:

Go

Go supported is included here in bazel-gazelle, see below.
Haskell

Tweag's rules_haskell has two extensions: gazelle_cabal, for generating rules from Cabal files and gazelle_haskell_modules for even more fine-grained build definitions.
Java

bazel-contrib's rules_jvm extensions include a gazelle extension for generating java_library, java_binary, java_test, and java_test_suite rules.
JavaScript / TypeScript

Aspect provides JavaScript and TypeScript Support in aspect-cli (also usable separately).

BenchSci's rules_nodejs_gazelle supports generating ts_project, js_library, jest_test, and web_asset rules, and is able to support module bundlers like Webpack and Next.js
Kotlin

Aspect Build provides some Kotlin Support in the repo of their aspect-cli (also usable separately). Still under development, please check the README for currently available features.
Protocol Buffers

Support for the proto_library rule, as well as go_proto_library is in this repository, see below. Other language-specific proto rules are not supported here. stackb/rules_proto is a good resource for these rules.
Python

rules_python has an extension for generating py_library, py_binary, and py_test rules.
R

rules_r has an extension for generating rules for R package builds and tests.
Rust

gazelle_rust is an extension for generating rules_rust targets.
Starlark

bazel-skylib has an extension for generating bzl_library rules. See bazel_skylib//gazelle/bzl.
Swift

rules_swift_package_manager has an extension for generating swift_library, swift_binary, and swift_test rules. It also includes facilities for resolving, downloading and building external Swift packages for a Bazel workspace.

If you know of an extension which could be linked here, please open a PR!

More languages can be added by Extending Gazelle. Chat with us in the #gazelle channel on Bazel Slack if you'd like to discuss your design.

If you've written your own extension, please consider open-sourcing it for use by the rest of the community. Note that such extensions belong in a language-specific repository, not in bazel-gazelle. See discussion in #1030.

Setup

Running Gazelle with Bazel

To use Gazelle in a new project, add the bazel_gazelle repository and its dependencies to your WORKSPACE file and call gazelle_dependencies. It should look like this:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "80a98277ad1311dacd837f9b16db62887702e9f1d1c4c9f796d0121a46c8e184",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.46.0/rules_go-v0.46.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.46.0/rules_go-v0.46.0.zip",
    ],
)

http_archive(
    name = "bazel_gazelle",
    integrity = "sha256-MpOL2hbmcABjA1R5Bj2dJMYO2o15/Uc5Vj9Q0zHLMgk=",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.35.0/bazel-gazelle-v0.35.0.tar.gz",
        "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.35.0/bazel-gazelle-v0.35.0.tar.gz",
    ],
)


load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies", "go_repository")

############################################################
# Define your own dependencies here using go_repository.
# Else, dependencies declared by rules_go/gazelle will be used.
# The first declaration of an external repository "wins".
############################################################

go_rules_dependencies()

go_register_toolchains(version = "1.20.5")

gazelle_dependencies()

gazelle_dependencies supports optional argument go_env (dict-mapping) to set project specific go environment variables. If you are using a WORKSPACE.bazel file, you will need to specify that using:

gazelle_dependencies(go_repository_default_config = "//:WORKSPACE.bazel")

Add the code below to the BUILD or BUILD.bazel file in the root directory of your repository.

Important: For Go projects, replace the string after prefix with the portion of your import path that corresponds to your repository.

load("@bazel_gazelle//:def.bzl", "gazelle")

# gazelle:prefix github.com/example/project
gazelle(name = "gazelle")

After adding this code, you can run Gazelle with Bazel.

$ bazel run //:gazelle

This will generate new BUILD.bazel files for your project. You can run the same command in the future to update existing BUILD.bazel files to include new source files or options.

You can write other gazelle rules to run alternate commands like update-repos.

gazelle(
    name = "gazelle-update-repos",
    args = [
        "-from_file=go.mod",
        "-to_macro=deps.bzl%go_dependencies",
        "-prune",
    ],
    command = "update-repos",
)

You can also pass additional arguments to Gazelle after a -- argument.

$ bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro=deps.bzl%go_dependencies

After running update-repos, you might want to run bazel run //:gazelle again, as the update-repos command can affect the output of a normal run of Gazelle.

Running Gazelle with Go

If you have a Go toolchain installed, you can install Gazelle with the command below:

go install github.com/bazelbuild/bazel-gazelle/cmd/gazelle@latest

Make sure to re-run this command to upgrade Gazelle whenever you upgrade rules_go in your repository.

To generate BUILD.bazel files in a new project, run the command below, replacing the prefix with the portion of your import path that corresponds to your repository.

gazelle -go_prefix github.com/example/project

Most of Gazelle's command-line arguments can be expressed as special comments in build files. See Directives below. You may want to copy this line into your root build files to avoid having to type -go_prefix every time.

# gazelle:prefix github.com/example/project

Compatibility with Go

Gazelle is compatible with supported releases of Go, per the Go Release Policy. The Go Team officially supports the current and previous minor releases. Older releases are not supported and don't receive bug fixes or security updates.

Gazelle may use language and library features from the oldest supported release.

Compatibility with rules_go

Gazelle generates build files that use features in newer versions of rules_go. Newer versions of Gazelle may generate build files that work with older versions of rules_go, but check the table below to ensure you're using a compatible version.

Gazelle version	Minimum rules_go version	Maximum rules_go version
0.8	0.8	n/a
0.9	0.9	n/a
0.10	0.9	0.11
0.11	0.11	0.24
0.12	0.11	0.24
0.13	0.13	0.24
0.14	0.13	0.24
0.15	0.13	0.24
0.16	0.13	0.24
0.17	0.13	0.24
0.18	0.19	0.24
0.19	0.19	0.24
0.20	0.20	0.24
0.21	0.20	0.24
0.22	0.20	0.24
0.23	0.26	0.28
0.24	0.29	0.40
0.25	0.29	0.40
0.26	0.29	0.40
0.27	0.29	0.40
0.28	0.35	0.40
0.29	0.35	0.40
0.30	0.35	0.40
0.31	0.35	0.40
0.32	0.41	n/a
0.33	0.41	n/a
0.34	0.41	n/a
0.35	0.41	n/a

Usage

Command line

gazelle <command> [flags...] [package-dirs...]

The first argument to Gazelle may be one of the commands below. If no command is specified, update is assumed. The remaining arguments are specific to each command and are documented below.

update: Scans sources files, then generates and updates build files.
fix: Same as the update command, but it also fixes deprecated usage of rules.
update-repos: Adds and updates repository rules in the WORKSPACE file.

Bazel rule

Gazelle may be run via a rule. See Running Gazelle with Bazel for setup instructions. This rule builds Gazelle and generates a wrapper script that executes Gazelle with baked-in set of arguments. You can run this script with bazel run, or you can copy it into your workspace and run it directly.

The following attributes are available on the gazelle rule.

Name	Type	Default value
`gazelle`	label	`@bazel_gazelle//cmd/gazelle`
The gazelle_binary version of Gazelle wit	rule that builds Gazel h this. See `Extending	le. You can substitute a modified Gazelle`_.
`external`	string	`external`
The method for resolvi `external`, :va See `Dependency resolu	ng unknown imports to lue:static or :value tion`_.	Bazel dependencies. May be :vendored.
`build_tags`	string_list	`[]`
The list of Go build t	ags that Gazelle shoul	d consider to always be true.
`prefix`	string	`""`
The import path that c Note: It's usually bet ``# gazelle:prefix exa this attribute.	orresponds to the repo ter to write a directi mple.com/repo`` in you	sitory root directory. ve like r build file instead of setting
`extra_args`	string_list	`[]`
A list of extra comman `extra_args` are sup ``bazel run //:gazelle See https://github.com	d line arguments passe pressed by extra comma -- subdir``). /bazelbuild/bazel-gaze	d to Gazelle. Note that nd line args (e.g. lle/issues/536 for explanation.
`command`	string	`update`
The Gazelle command to `update-repos`.	use. May be :value:`f	ix`, `update` or

`fix` and `update`

The update command is the most common way of running Gazelle. Gazelle scans sources in directories throughout the repository, then creates and updates build files.

The fix command does everything update does, but it also fixes deprecated usage of rules, analogous to go fix. For example, cgo_library will be consolidated with go_library. This command may delete or rename rules, so it's not on by default. See Fix command transformations for details.

Both commands accept a list of directories to process as positional arguments. If no directories are specified, Gazelle will process the current directory. Subdirectories will be processed recursively.

The following flags are accepted:

Name	Default value
`-build_file_name file1,file2,...`	`BUILD.bazel,BUILD`
Comma-separated list of file names. Gazelle recognizes these files build files. New files will use the first name in this list. Use th your project contains non-Bazel files named `BUILD` (or `build` case-insensitive file systems).	as Bazel is if on
`-build_tags tag1,tag2`
List of Go build tags Gazelle will consider to be true. Gazelle app constraints when generating Go rules. It assumes certain tags are t certain platforms (for example, `amd64,linux`). It assumes all Go tags are true (for example, `go1.8`). It considers other tags to (for example, `ignore`). This flag overrides that behavior. Bazel may still filter sources with these tags. Use `bazel build --define gotags=foo,bar` to set tags at build time.	lies rue on release be false
`-exclude pattern`
Prevents Gazelle from processing a file or directory if the given doublestar.Match pattern matches. If the pattern refers to a sou Gazelle won't include it in any rules. If the pattern refers to a d Gazelle won't recurse into it. This option may be repeated. Patterns must be slash-separated, rela repository root. This is equivalent to the ``# gazelle:exclude patt directive.	rce file, irectory, tive to the ern``
`-external external\|static\|vendored`	`external`
Determines how Gazelle resolves import paths that cannot be resolve current repository. May be `external`, `static` or :v Dependency resolution.	in the alue:vendored. See
`-index true\|false`	`true`
Determines whether Gazelle should index the libraries in the curren should use the index to resolve dependencies. If this is switched o `# gazelle:prefix` directive or `-go_prefix` flag to resolve de	t repository and whether it ff, Gazelle would rely on pendencies.
`-go_grpc_compiler`	`@io_bazel_rules_go//proto:go_grpc`
The protocol buffers compiler to use for building go bindings for g See Predefined plugins for available options; commonly used opti `@io_bazel_rules_go//proto:gofast_grpc` and ``@io_bazel_rules_go/	RPC. May be repeated. ons include /proto:gogofaster_grpc``.
`-go_naming_convention`
Controls the names of generated Go targets. Equivalent to the `# gazelle:go_naming_convention` directive. See details in Directives below.
`-go_naming_convention_external`
Controls the default naming convention used when resolving librarie external repositories with unknown naming conventions. Equivalent t `# gazelle:go_naming_convention_external` directive.	s in o the
`-go_prefix example.com/repo`
A prefix of import paths for libraries in the repository that corre the repository root. Equivalent to setting the `# gazelle:prefix` in the root BUILD.bazel file or the `prefix` attribute of the ``g neither of those are set, this option is mandatory. This prefix is used to determine whether an import path refers to a in the current repository or an external dependency.	sponds to directive azelle`` rule. If library
`-go_proto_compiler`	`@io_bazel_rules_go//proto:go_proto`
The protocol buffers compiler to use for building go bindings. May See Predefined plugins for available options; commonly used opti `@io_bazel_rules_go//proto:gofast_proto` and ``@io_bazel_rules_go	be repeated. ons include //proto:gogofaster_proto``.
`-known_import example.com`
Skips import path resolution for a known domain. May be repeated. When Gazelle resolves an import path to an external dependency, it to discover the remote repository root over HTTP. Gazelle skips thi discovery step for a few well-known domains with predictable struct golang.org and github.com. This flag specifies additional domains t which is useful in situations where the lookup would fail for some	attempts s ure, like o skip, reason.
`-mode fix\|print\|diff`	`fix`
Method for emitting merged build files. In `fix` mode, Gazelle writes generated and merged files to disk. `print` mode, it prints them to stdout. In `diff` mode, it prin unified diff.	In ts a
`-proto default\|file\|package\|legacy\|disable\|disable_global`	`default`
Determines how Gazelle should generate rules for .proto files. See in Directives below.	details
`-proto_group group`	:value:""
Determines the proto option Gazelle uses to group .proto files into when in `package` mode. See details in Directives below.	rules
`-proto_import_prefix path`
Sets the import_prefix attribute of generated `proto_library` This adds a prefix to the string used to import `.proto` files li the `srcs` attribute of generated rules. Equivalent to the `# gazelle:proto_import_prefix` directive. See details in `Direct	rules. sted in ives`_ below.
`-repo_root dir`
The root directory of the repository. Gazelle normally infers this directory containing the WORKSPACE file. Gazelle will not process packages outside this directory.	to be the
`-lang lang1,lang2,...`	`""`
Selects languages for which to compose and index rules. By default, all languages that this Gazelle was built with are proc	essed.
`-cpuprofile filename`	`""`
If specified, gazelle uses [runtime/pprof](https://pkg.go.dev/runti CPU profiling information from the command and save it to the given By default, this is disabled	me/pprof#StartCPUProfile) to collect file.
`-memprofile filename`	`""`
If specified, gazelle uses [runtime/pprof](https://pkg.go.dev/runti memory a profile information from the command and save it to a file By default, this is disabled	me/pprof#WriteHeapProfile) to collect .

`update-repos`

The update-repos command updates repository rules. It can write the rules to either the WORKSPACE (by default) or a .bzl file macro function. It can be used to add new repository rules or update existing rules to the specified version. It can also import repository rules from a go.mod or a go.work file.

WARNING: This command is mainly used for managing external Go dependencies in Bazel's WORKSPACE mode. For managing external Go dependencies in Bazel's BzlMod mode, please check: https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md#external-dependencies

# Add or update a repository to latest version by import path
$ gazelle update-repos example.com/new/repo

# Add or update a repository to specified version/commit by import path
$ gazelle update-repos example.com/new/[email protected]

# Import repositories from go.mod
$ gazelle update-repos -from_file=go.mod

# Import repositories from go.work
$ gazelle update-repos -from_file=go.work

# Import repositories from go.mod and update macro
$ gazelle update-repos -from_file=go.mod -to_macro=repositories.bzl%go_repositories

# Import repositories from go.work and update macro
$ gazelle update-repos -from_file=go.work -to_macro=repositories.bzl%go_repositories

The following flags are accepted:

Name	Default value
`-from_file lock-file`
Import repositories from a file as go_repository rules. These rules will be added to the bottom of the The lock file format is inferred from the file name. `go.mod` and `go.work are all supported.	WORKSPACE file or merged with existing rules.
`-repo_root dir`
The root directory of the repository. Gazelle normally infers this to be the directory containing the WORK Gazelle will not process packages outside this directory.	SPACE file.
`-to_macro macroFile%defName`
Tells Gazelle to write new repository rules into a .bzl macro function rather than the WORKSPACE file. The `repository_macro` directive should be added to the WORKSPACE in order for future Gazelle calls to r	ecognize the repos defined in the macro file.
`-prune true\|false`	`false`
When true, Gazelle will remove go_repository rules that no longer have equivalent repos in the `go.mod This flag can only be used with`-from_file``.	`` file.
`-build_directives arg1,arg2,...`
Sets the `build_directives attribute` for the generated go_repository rule(s).
`-build_external external\|vendored`
Sets the `build_external` attribute for the generated go_repository rule(s).
`-build_extra_args arg1,arg2,...`
Sets the `build_extra_args attribute` for the generated go_repository rule(s).
`-build_file_generation auto\|on\|off`
Sets the `build_file_generation` attribute for the generated go_repository rule(s).
`-build_file_names file1,file2,...`
Sets the `build_file_name` attribute for the generated go_repository rule(s).
`-build_file_proto_mode default\|package\|legacy\|disable\|disable_global`
Sets the `build_file_proto_mode` attribute for the generated go_repository rule(s).
`-build_tags tag1,tag2,...`
Sets the `build_tags` attribute for the generated go_repository rule(s).

Directives

Gazelle can be configured with directives, which are written as top-level comments in build files. Most options that can be set on the command line can also be set using directives. Some options can only be set with directives.

Directive comments have the form # gazelle:key value. For example:

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

# gazelle:prefix github.com/example/project
# gazelle:build_file_name BUILD,BUILD.bazel

go_library(
    name = "go_default_library",
    srcs = ["example.go"],
    importpath = "github.com/example/project",
    visibility = ["//visibility:public"],
)

Directives apply in the directory where they are set and in subdirectories. This means, for example, if you set # gazelle:prefix in the build file in your project's root directory, it affects your whole project. If you set it in a subdirectory, it only affects rules in that subtree.

The following directives are recognized:

Directive	Default value
`# gazelle:build_file_name names`	`BUILD.bazel,BUILD`
Comma-separated list of file names. Gazelle recogni build files. New files will use the first name in t your project contains non-Bazel files named ``BUILD case-insensitive file systems).	zes these files as Bazel his list. Use this if `(or`build`` on
`# gazelle:build_tags foo,bar`	none
List of Go build tags Gazelle will consider to be t constraints when generating Go rules. It assumes ce certain platforms (for example, `amd64,linux`). I tags are true (for example, `go1.8`). It consider (for example, `ignore`). This flag overrides that Bazel may still filter sources with these tags. Use `bazel build --define gotags=foo,bar` to set tags	rue. Gazelle applies rtain tags are true on t assumes all Go release s other tags to be false behavior. at build time.
`# gazelle:exclude pattern`	n/a
Prevents Gazelle from processing a file or director doublestar.Match pattern matches. If the pattern Gazelle won't include it in any rules. If the patte Gazelle won't recurse into it. This directive may b multiple patterns, one per line.	y if the given refers to a source file, rn refers to a directory, e repeated to exclude
`# gazelle:follow pattern`	n/a
Instructs Gazelle to follow a symbolic link to a di given doublestar.Match pattern matches. Normally links unless they point outside of the repository r Care must be taken to avoid visiting a directory mo The `# gazelle:exclude` directive may be used to recursing into a directory.	rectory within the repository if the , Gazelle does not follow symbolic oot. re than once. prevent Gazelle from
`# gazelle:go_generate_proto`	`true`
Instructs Gazelle's Go extension whether to generat `proto_library` rules generated by the Proto exte Gazelle will generate `go_proto_library` and `go`# gazelle:proto`. When this directive is`false `proto_library` rules. If there are any pre-gener regular Go files.	e `go_proto_library` rules for nsion. When this directive is `true` _library`according to`, the Go extension will ignore any ated Go files, they will be treated as
`# gazelle:go_test mode`	`default`
Tells Gazelle how to generate rules for _test.go fi `default`: One `go_test` rule will be generat all `_test.go` files in the directory. `file`: A distinct `go_test` rule will be gen package directory.	les. Valid values are: ed whose `srcs` includes erated for each `_test.go` file in the
`# gazelle:go_grpc_compilers`	`@io_bazel_rules_go//proto:go_grpc`
The protocol buffers compiler(s) to use for buildin Multiple compilers, separated by commas, may be spe Omit the directive value to reset go_grpc_compile See `Predefined plugins`_ for available options; co@io_bazel_rules_go//proto:gofast_grpc`and`@io_bazel_rules_go//proto:gogofaster_grpc``.	g go bindings for gRPC. cified. rs`` back to the default. mmonly used options include
`# gazelle:go_naming_convention`	inferred automatically
Controls the names of generated Go targets. Valid values are: `go_default_library`: Library targets are named are named `go_default_test`. `import`: Library and test targets are named af path. For example, `example.repo/foo` is named foo` Major version suffixes like/v2`are dropped. For a main package with a binary`foobin`, the`foobin_test``. `import_alias`: Same as `import`, but an `al`go_default_library`` to ensure backwards compat If no naming convention is set, Gazelle attempts to use by reading the root build file and build files subdirectories. If no Go targets are found, Gazelle	`go_default_library`, test targets ter the last segment of their import , and the test target is foo_test`. names are instead `foobin_lib` and ias`target is generated named ibility. infer the convention in in immediate defaults to`import``.
`# gazelle:go_naming_convention_external`	n/a
Controls the default naming convention used when re external repositories with unknown naming conventio as `go_naming_convention`.	solving libraries in ns. Accepts the same values
`# gazelle:go_proto_compilers`	`@io_bazel_rules_go//proto:go_proto`
The protocol buffers compiler(s) to use for buildin Multiple compilers, separated by commas, may be spe Omit the directive value to reset go_proto_compil See `Predefined plugins`_ for available options; co@io_bazel_rules_go//proto:gofast_proto`and`@io_bazel_rules_go//proto:gogofaster_proto``.	g go bindings. cified. ers`` back to the default. mmonly used options include
`# gazelle:ignore`	n/a
Prevents Gazelle from modifying the build file. Gaz rules in the build file and may modify build files	elle will still read in subdirectories.
`# gazelle:importmap_prefix path`	See below
A prefix for `importmap` attributes in library ru an `importmap` on a `go_library` or `go_proto_ concatenating this with the relative path from the prefix is set to the library. For example, if`imp to `"x/example.com/repo"` in the build file `//f then a library in`foo/bar/baz`will have the`i `"x/example.com/repo/baz"`. `importmap` is not set when it matches `importpa As a special case, when Gazelle enters a directory sets`importmap_prefix`to a string based on the location of the vendor directory. If you wish to ov to set`importmap_prefix`` explicitly in the vendo	les. Gazelle will set library`by directory where the ortmap_prefix` is set oo/bar:BUILD.bazel`, mportmap` of th`. named`vendor``, it repository name and the erride this, you'll need r directory.
:direc:`# gazelle:map_kind from_kind to_kind to_kin	d_load` \| n/a
Customizes the kind of rules generated by Gazelle. As a separate step after generating rules, any new kind replaced with `to_kind`. This means that `t parameters and behave similarly. Most commonly, this would be used to replace the ru custom macros. For example,`gazelle:map_kind go_binary go_deployable //tools/ produce rules of kind `go_deployable` as loaded f `go_binary`, for this directory or within. Existing rules of the old kind will be ignored. To kind to a mapped kind, use buildozer.	rules of kind `from_kind` have their o_kind`must accept the same les provided by`rules_go`with go:def.bzl` would configure Gazelle to rom `//tools/go:def.bzl` instead of switch your codebase from a builtin
`# gazelle:prefix path`	n/a
A prefix for `importpath` attributes on library r an `importpath` on a `go_library` or `go_proto concatenating this with the relative path from the prefix is set to the library. Most commonly,`pref name of a repository in the root directory of a rep in this repository, `prefix` is set in `//:BUILD`github.com/bazelbuild/bazel-gazelle`. The`go_l `//cmd/gazelle` is assigned the `importpath` `"github.com/bazelbuild/bazel-gazelle/cmd/gazelle" As a special case, when Gazelle enters a directory`prefix`to the empty string. This automatically an intuitive`importpath``.	ules. Gazelle will set _library`by directory where the ix` is set to the ository. For example, .bazel`to ibrary` in `. named`vendor``, it sets gives vendored libraries
`# gazelle:proto mode`	`default`
Tells Gazelle how to generate rules for .proto file `default`: `proto_library`, `go_proto_librar rules are generated using`@io_bazel_rules_go//p of each rule may be generated per directory. This `file`: a `proto_library` rule is generated f `package`: multiple `proto_library` and ``go may be generated in the same directory. .proto fi rules based on their package name or another opti `legacy`: `filegroup` rules are generated for @io_bazel_rules_go//proto:go_proto_library.bzl` rules must be written by hand. Gazelle will run i ifgo_proto_library.bzl`` is loaded to avoid di projects, but this can be overridden with a direc `disable`: .proto files are ignored. Gazelle wi automatically if `go_proto_library` is loaded f but this can be overridden with a directive. `disable_global`: like `disable` mode, but al using any special cases in dependency resolution Google APIs. Useful for avoiding build-time depen This directive applies to the current directory and special case, when Gazelle enters a directory named mode isn't set explicitly in a parent directory or Gazelle will run in `disable` mode. Additionally, `@io_bazel_rules_go//proto:go_proto_library.bzl` will run in `legacy` mode.	Valid values are: y`, and`go_library`roto:def.bzl`. Only one is the default mode. or every .proto file. proto_library`rules les are grouped into on (see`proto_group). use by `.go_proto_library`n this mode automatically srupting existing tive. ll run in this mode rom any other source, so prevents Gazelle from for Well Known Types and dencies on protoc. subdirectories. As a`vendor``, if the proto on the command line, if the file is loaded, Gazelle
`# gazelle:proto_group option`	`""`
This directive is only effective in `package` * Specifies an option that Gazelle can use to group . For example, when set to `go_package`, .proto fil `option go_package` will be grouped together. When this directive is set to the empty string, Gaz by their proto package statement. Rule names are generated based on the last run of i in the package name. For example, if the package is `proto_library` rule will be named `baz_proto`.	mode (see above).* proto files into rules. es with the same elle will group packages dentifier characters `"foo/bar/baz"`, the
`# gazelle:proto_import_prefix path`	n/a
Sets the import_prefix attribute of generated `This adds a prefix to the string used to import`. the `srcs` attribute of generated rules. For example, if the target `//a:b_proto` has `sr`import_prefix = "github.com/x/y"`, then`b.prot with the string `"github.com/x/y/a/b.proto"`.	proto_library`rules. proto` files listed in cs = ["b.proto"]`and o` should be imported
`# gazelle:proto_strip_import_prefix path`	n/a
Sets the strip_import_prefix attribute of genera This is a prefix to strip from the strings used to If the prefix starts with a slash, it's intepreted root. Otherwise, it's relative to the directory con The package-relative form is only useful when a sin `.proto` files in subdirectories. Gazelle doesn't this, so only paths with a leading slash should be a warning when the package-relative form is used. For example, if the target `//proto/a:b_proto` ha and `strip_import_prefix = "/proto"`, then `b.pr with the string`"a/b.proto"``.	ted `proto_library` rules. import `.proto` files. relative to the repository taining the build file. gle build file covers generate build files like used. Gazelle will print s `srcs = ["b.proto"]` oto`` should be imported
`# gazelle:resolve ...`	n/a
Specifies an explicit mapping from an import string Dependency resolution. The format for a resolve `# gazelle:resolve source-lang import-lang import- `source-lang`is the language of the source cod `import-lang`is the language importing the lib the same as`source-lang`but may differ with g example, when resolving dependencies for a`go_p `source-lang` would be `"proto"` and `import`import-lang`` may be omitted if it is the same `import-string` is the string used in source co `label` is the Bazel label that Gazelle should For example: # gazelle:resolve go example.com/foo //foo:go_def # gazelle:resolve proto go foo/foo.proto //foo:fo	to a label for directive is: string label`e being imported. rary. This is usually enerated code. For roto_library`, -lang`would be`"go"`. as`source-lang`. de to import a library. write in`deps``. ault_library o_go_proto
`# gazelle:resolve_regexp ...`	n/a
Specifies an explicit mapping from an import regex Dependency resolution. The format for a resolve `# gazelle:resolve_regexp source-lang import-lang `source-lang`is the language of the source cod `import-lang`is the language importing the lib the same as`source-lang`but may differ with g example, when resolving dependencies for a`go_p `source-lang` would be `"proto"` and `import`import-lang`` may be omitted if it is the same * `import-string-regex` is the regex applied to t If it matches, that import will be resolved to th `label` is the Bazel label that Gazelle should For example: # gazelle:resolve_regexp go example.com/.* //foo: # gazelle:resolve_regexp proto go foo/.*\.proto /	to a label for directive is: import-string-regex label`e being imported. rary. This is usually enerated code. For roto_library`, -lang`would be`"go"`. as`source-lang`. he import in the source code. e label specified below. write in`deps``. go_default_library /foo:foo_go_proto
`# gazelle:go_visibility label`	n/a
By default, internal packages are only visible to i internal packages should be visible to additionally times, adding a list of labels.	ts siblings. This directive adds a label . This directive can be used several
`# gazelle:lang lang1,lang2,...`	n/a
Sets the language selection flag for this and desce index and generate rules for only the languages nam	ndent packages, which causes gazelle to ed in this directive.
`# gazelle:default_visibility visibility`	n/a
Comma-separated list of visibility specifications. This directive adds the visibility specifications f For example: # gazelle:default_visibility //foo:__subpackages_	or this and descendant packages. _,//src:__subpackages__

Gazelle also reads directives from the WORKSPACE file. They may be used to discover custom repository names and known prefixes. The fix and update commands use these directives for dependency resolution. update-repos uses them to learn about repository rules defined in alternate locations.

WORKSPACE Directive	Default value
`# gazelle:repository_macro [+]macroFile%defName`	n/a
Tells Gazelle to look for repository rules in a macro in a .bzl file repeated multiple times. The macro can be generated by calling `update-repos` with the ``to The directive can be prepended with a "+", which will tell Gazelle t within any macros called by the specified macro.	. The directive can be _macro`` flag. o also look for repositories
`# gazelle:repository rule_kind attr1_name=attr1_value ...`	n/a
Specifies a repository rule that Gazelle should know about. The dire and can be declared from within a macro definition that Gazelle know directive must define a rule kind and a name attribute, but it can d This is useful for teaching Gazelle about repos declared in external to override an actual repository rule. For example, a `git_reposito could be overriden with the directive: .. code:: bzl # gazelle:repository go_repository name=org_golang_x_tools importp Gazelle would then proceed as if`org_golang_x_tools`` was declared	ctive can be repeated multiple times, s about. At the very least the efine extra attributes after that. macros. The directive can also be used ry`rule for`org_golang_x_tools`ath=golang.org/x/tools as a`go_repository`` rule.

Keep comments

In addition to directives, Gazelle supports # keep comments that protect parts of build files from being modified. # keep may be written before a rule, before an attribute, or after a string within a list.

# keep comments might take one of 2 forms; the # keep literal or a description prefixed by # keep:.

Example

Suppose you have a library that includes a generated .go file. Gazelle won't know what imports to resolve, so you may need to add dependencies manually with # keep comments.

load("@io_bazel_rules_go//go:def.bzl", "go_library")
load("@com_github_example_gen//:gen.bzl", "gen_go_file")

gen_go_file(
    name = "magic",
    srcs = ["magic.go.in"],
    outs = ["magic.go"],
)

go_library(
    name = "go_default_library",
    srcs = ["magic.go"],
    visibility = ["//visibility:public"],
    deps = [
        "@com_github_example_gen//:go_default_library",  # keep
        "@com_github_example_gen//a/b/c:go_default_library",  # keep: this is also important
    ],
)

Dependency resolution

One of Gazelle's most important jobs is resolving library import strings (like import "golang.org/x/sys/unix") to Bazel labels (like @org_golang_x_sys//unix:go_default_library). Gazelle follows the rules below to resolve dependencies:

If the import to be resolved is part of a standard library, no explicit dependency is written. For example, in Go, you don't need to declare that you depend on "fmt".
If a # gazelle:resolve directive matches the import to be resolved, the label at the end of the directive will be used.
If proto rule generation is enabled, special rules will be used when importing certain libraries. These rules may be disabled by adding # gazelle:proto disable_global to a build file (this will affect subdirectories, too) or by passing -proto disable_global on the command line.
1. Imports of Well Known Types are mapped to rules in @io_bazel_rules_go//proto/wkt.
2. Imports of Google APIs are mapped to @go_googleapis.
3. Imports of github.com/golang/protobuf/ptypes, descriptor, and jsonpb are mapped to special rules in @com_github_golang_protobuf. See Avoiding conflicts with proto rules.
If the import to be resolved is in the library index, the import will be resolved to that library. If -index=true, Gazelle builds an index of library rules in the current repository before starting dependency resolution, and this is how most dependencies are resolved.
1. For Go, the match is based on the importpath attribute.
2. For proto, the match is based on the srcs attribute.
If -index=false and a package is imported that has the current go_prefix as a prefix, Gazelle generates a label following a convention. For example, if the build file in //src set the prefix with # gazelle:prefix example.com/repo/foo, and you import the library "example.com/repo/foo/bar, the dependency will be "//src/foo/bar:go_default_library".
Otherwise, Gazelle will use the current external mode to resolve the dependency.
1. In external mode (the default), Gazelle will transform the import string into an external repository label. For example, "golang.org/x/sys/unix" would be resolved to "@org_golang_x_sys//unix:go_default_library". Gazelle does not confirm whether the external repository is actually declared in WORKSPACE, but if there is a go_repository in WORKSPACE with a matching importpath, Gazelle will use its name. Gazelle does not index rules in external repositories, so it's possible the resolved dependency does not exist.
2. In static mode, Gazelle has the same behavior as external mode, except that it will not call out to the network for resolution when no matching import is found within WORKSPACE. Instead, it will skip the unknown import. This is the default mode for go_repository rules.
3. In vendored mode, Gazelle will transform the import string into a label in the vendor directory. For example, "golang.org/x/sys/unix" would be resolved to "//vendor/golang.org/x/sys/unix:go_default_library". This mode is usually not necessary, since vendored libraries will be indexed and resolved using rule 4.

Fix command transformations

Gazelle will generate and update build files when invoked with either gazelle update or gazelle fix (update is the default). Both commands perform several transformations to fix deprecated usage of the Go rules. update performs a safe set of tranformations, while fix performs some additional transformations that may delete or rename rules.

The following transformations are performed:

Migrate library to embed (fix and update): Gazelle replaces library attributes with embed attributes.

Migrate gRPC compilers (fix and update): Gazelle converts go_grpc_library rules to go_proto_library rules with compilers = ["@io_bazel_rules_go//proto:go_grpc"].

Flatten srcs (fix and update): Gazelle converts srcs attributes that use OS and architecture-specific select expressions to flat lists. rules_go filters these sources anyway.

Squash cgo libraries (fix only): Gazelle will remove cgo_library rules named cgo_default_library and merge their attributes with a go_library rule in the same package named go_default_library. If no such go_library rule exists, a new one will be created. Other cgo_library rules will not be removed.

Squash external tests (fix only): Gazelle will squash go_test rules named go_default_xtest into go_default_test. Earlier versions of rules_go required internal and external tests to be built separately, but this is no longer needed.

Remove legacy protos (fix only): Gazelle will remove usage of go_proto_library rules loaded from @io_bazel_rules_go//proto:go_proto_library.bzl and filegroup rules named go_default_library_protos. Newly generated proto rules will take their place. Since filegroup isn't needed anymore and go_proto_library has different attributes and was always written by hand, Gazelle will not attempt to merge anything from these rules with the newly generated rules.

This transformation is only applied in the default proto mode. Since Gazelle will run in legacy proto mode if go_proto_library.bzl is loaded, this transformation is not usually applied. You can set the proto mode explicitly using the directive # gazelle:proto default.

Update loads of gazelle rule (fix and update): Gazelle will remove loads of gazelle from @io_bazel_rules_go//go:def.bzl. It will automatically add a load from @bazel_gazelle//:def.bzl if gazelle is not loaded from another location.

bazel-gazelle's People

Contributors

Stargazers

Watchers

Forkers

jayconrod diegs willtrking ali5h improbable-archive helcaraxan yasushi-saito ixdy nictuku globegitter mikedanese evie404 emcfarlane ando-masaki prestonvanloon rohanag12 raliste happy-ferret anima-os-stash mistobaan ben-ng achew22 lubinsz lubinszarm pmuetschard atlassian yasitashiki nikhita clnperez rutsky rainbowfhb yannic kalbasit chressie zhaolion filipesilva thatsmrtalbot bombela yaozongyou weixiao-huang joe-mann namtzigla jaredneil laurentlb andrew-d robfig mirandacong jmhodges linzhp dfinkel mjduijn vam-google dtbartle bartle-stripe gauntletwizard blico jen20 renovate-bot robbertvanginkel portalgun-io filmil andrew-stripe tony84727 ivanium keizo042 jasharpe clintharrison hfghgakjd bigkraig omnicate ashi009 uber-common jmillikin-stripe briantopping rshirani asuffield xindahuang abelgana odinuge xjs tmhdgsn cwaeland isgasho mbrukman asv ikorolev93 pranavsharma97 clarecat zhang3r ebracho sataqiu zoidyzoidzoid liggitt jsdt dududko cjds tomaszstrejczek pcj tomlu henrywu2019

bazel-gazelle's Issues

Tests with importpath but no sources are not deleted

For example, in https://github.com/kubernetes/sample-controller/blob/master/vendor/k8s.io/api/core/v1/BUILD, the go_default_test rule should be deleted since it has no sources. After running Gazelle, that rule is left behind with name and importpath attributes.

The problem is that importpath is no longer considered a mergeable attribute for go_test and go_binary, so it won't get removed, and the rule won't be considered empty. Currently, rules are considered empty if they have no attributes other than name and visibility.

We should expand the definition of empty: rules generated by Gazelle that have no srcs, deps, or embed attributes after merge should be deleted. This should catch go_binary with manually set goos and goarch as well.

Gazelle should exit with an error code when encountering errors in a development repository

Migrated from bazelbuild/rules_go#955

First raised on bazel-go-discuss by @hochhaus.

Gazelle is fairly error-tolerant because we use it in go_repository, and we need it to partially succeed when it runs into invalid code (this is especially a problem in testdata directories for tools that operate on Go code).

It doesn't make sense for Gazelle to be so tolerant when run manually in one's own project though. Ideally, Gazelle should accept a flag (which is only provided in go_repository) which would turn off exit codes for non-fatal errors.

Add directive to skip generating a specific rule

Migrated from bazelbuild/rules_go#788

For example, you could prevent Gazelle from generating a test for in a certain package using a directive like this:

# gazelle:skip go_default_test

Support multiple prefixes

(Originally bazelbuild/rules_go#313)

Gazelle should recognize directives like # gazelle:prefix example.com/my/project. This should define the prefix for the directory where they are defined and subdirectories.

Gazelle should not require a -go_prefix argument on the command line if a directive like this is found in the top-level build file.

This would be useful for monorepos with (possibly multiple) Go subtrees that aren't at the repository root.

Disable proto rule generation by default in vendor

Original issue: bazelbuild/rules_go#1219, bazelbuild/rules_go#1022

Vendored .proto files rarely compile without modification in Bazel. If a vendored proto A imports another vendored proto B, the import path in A must be adjusted manually to include a "vendor" prefix. Bazel proto_library assumes all proto import paths are relative to the root of a repository. There's currently no way to adjust import paths via proto_library.

Since working proto_library rules can't be generated for vendored protos in most cases, Gazelle should not attempt to do so by default. We should automatically disable proto rule generation when entering a vendor directory.

Proto rule generation can be explicitly turned on by adding a directive like the one below to a build file. The directive applies to the build file's package and subdirectories.

# gazelle:proto default

Warn when an import can't be resolved

(Originally bazelbuild/rules_go#388)

Gazelle should warn developers when an import can't be resolved into a Bazel dependency.

Now that we have a library index, we can tell definitively whether this is an error for local imports (under some known prefix) and for non-local imports in vendored mode (since we index vendor folders). We don't yet have a reliable way to resolve imports in external repositories.

Gazelle doesn't update build files when all sources are removed

Migrated from bazelbuild/rules_go#939

Gazelle should remove all rules in the build file that it may have generated. Other rules should be left intact. If the build file is empty after removing rules, it should NOT be deleted.

Follow symlinks

(Originally bazelbuild/rules_go#520)

Gazelle should dereference symbolic links and treat them as whatever kind of file they point to. Currently, we use FileInfo.IsDir to decide whether a file is a subdirectory or not, but this returns false for symbolic links. We could end up reading these as files, depending on how they are named.

Test running gazelle rule in another workspace

Test should:

Create a new workspace with a WORKSPACE file, BUILD.bazel file, and some trivial source files, using the recommended boilerplate code.
bazel run //:gazelle
bazel build a newly generated go_binary rule.

This test should work similarly to rules_go integration tests (see bazel_tests.bzl).

`bazel run :gazelle` broken for Bazel 0.9.0

Hi all. I'm attempting to create a new Go project and initialized my repo with a rules_go and gazelle. When attempting to verify that all works by running bazel run gazelle I get the following output:

$ bazel run :gazelle
INFO: Analysed target //:gazelle (0 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  bazel-bin/gazelle.bash
INFO: Elapsed time: 0.589s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action

INFO: Running command line: bazel-bin/gazelle.bash
Loading: 
Loading: 0 packages loaded
ERROR: Skipping '//:gazelle': no such package '': BUILD file not found on package path
WARNING: Target pattern parsing failed.
ERROR: no such package '': BUILD file not found on package path
INFO: Elapsed time: 0.029s
FAILED: Build did NOT complete successfully (0 packages loaded)
FAILED: Build did NOT complete successfully (0 packages loaded)
error: /home/sadpengu/.cache/bazel/_bazel_sadpengu/ec883637456c7798d953715093f767e5/execroot/com_zenreach_hydroponics/bazel-out/k8-fastbuild/bin/gazelle.bash: script is out of date. Refresh it with the command:
  bazel build //:gazelle && cp -fv "" "/home/sadpengu/.cache/bazel/_bazel_sadpengu/ec883637456c7798d953715093f767e5/execroot/com_zenreach_hydroponics/bazel-out/k8-fastbuild/bin/gazelle.bash"
ERROR: Non-zero return code '1' from command: Process exited with status 1

I have three files in this repo:

WORKSPACE
BUILD.bazel
src/main.go

WORKSPACE:

workspace(
    name = "redacted",
)

http_archive(
    name = "io_bazel_rules_go",
    url = "https://github.com/bazelbuild/rules_go/releases/download/0.8.1/rules_go-0.8.1.tar.gz",
    sha256 = "90bb270d0a92ed5c83558b2797346917c46547f6f7103e648941ecdb6b9d0e72",
)
load("@io_bazel_rules_go//go:def.bzl", "go_rules_dependencies", "go_register_toolchains")
go_rules_dependencies()
go_register_toolchains()

http_archive(
    name = "bazel_gazelle",
    url = "https://github.com/bazelbuild/bazel-gazelle/releases/download/0.8/bazel-gazelle-0.8.tar.gz",
    sha256 = "e3dadf036c769d1f40603b86ae1f0f90d11837116022d9b06e4cd88cae786676",
)
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies")
gazelle_dependencies()

BUILD.bazel:

load("@bazel_gazelle//:def.bzl", "gazelle")

gazelle(
    name = "gazelle",
    prefix = "github.com/zenreach/redacted",
)

src/main.go:

package main

import "fmt"

func main() {
	fmt.Println("Hello, world!")
}

Output of bazel version:

$ bazel version
Build label: 0.9.0- (@non-git)
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Mar 21 00:11:16 +49984 (1515182371876)
Build timestamp: 1515182371876
Build timestamp as int: 1515182371876

My assumption, based on the output and contents of gazelle.bash.in, is that Bazel 0.9.0 no longer sets BAZEL_REAL and that's causing things not to work.

If I run bazel-bin/gazell.build directly from the root of my workspace things operate as expected:

$ ./bazel-bin/gazelle.bash
Loading: 
Loading: 0 packages loaded
INFO: Analysed target //:gazelle (0 packages loaded).
INFO: Found 1 target...
[0 / 1] [-----] BazelWorkspaceStatusAction stable-status.txt
Target //:gazelle up-to-date:
  bazel-bin/gazelle.bash
INFO: Elapsed time: 0.626s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
Loading: 
Loading: 0 packages loaded
INFO: Analysed target @bazel_gazelle//cmd/gazelle:gazelle (0 packages loaded).
INFO: Found 1 target...
[0 / 4] [-----] BazelWorkspaceStatusAction stable-status.txt
Target @bazel_gazelle//cmd/gazelle:gazelle up-to-date:
  bazel-bin/external/bazel_gazelle/cmd/gazelle/linux_amd64_stripped/gazelle
INFO: Elapsed time: 0.635s, Critical Path: 0.01s
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
$ cat src/BUILD.bazel 
load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")

go_library(
    name = "go_default_library",
    srcs = ["main.go"],
    importpath = "github.com/zenreach/redacted/src",
    visibility = ["//visibility:private"],
)

go_binary(
    name = "src",
    embed = [":go_default_library"],
    importpath = "github.com/zenreach/redacted/src",
    visibility = ["//visibility:public"],
)

Optionally disable generation of go_test rules for vendor and dependencies

(Migrated from bazelbuild/rules_go#725)

In some situations, it may be desirable to ignore tests in dependencies (both in vendor directories and in external repositories). Test rules may introduce additional dependencies and slow down the build.

It should be possible to disable generation of go_test rules via a directive or a command line option (to be passed through go_repository).

Use tool directives to resolve conflicts between rule generating tools

Gazelle should not modify rules, attributes, or expressions marked with # tool:<tool> comments. For example:

# tool:builderator
proto_library(
    name = "foo_proto",
    srcs = ["foo.proto"],
)

These comments should be treated the same as # keep comments unless the tool is gazelle, in which case, these comments should be ignored but preserved.

Comments like these should be respected by tools that generate and update rules in build files. In some cases, tools may want to modify the same rule, and we should provide users with a mechanism to resolve conflicts.

Gazelle doesn't know how to handle imports from `google/api/*.proto`

In a cursory glance it looks like these should come from https://github.com/googleapis/googleapis/blob/master/google/api/. Is it possible to specify that these are external deps and should be loaded from a @external_repo?

Use package name instead of go_default_library for rules

Originally bazelbuild/rules_go#265

We used go_default_library as the name for go_library rules generated by Gazelle to simplify dependency resolution. Both the Go rules and Gazelle relied on this, along with go_prefix.

Now, go_prefix is deprecated and Gazelle adds importpath attributes to all Go rules. It also uses an index for dependency resolution instead of transforming import path strings. There's no longer a technical need for go_default_library, so we'd like to migrate away from that name.

In general, we'd like the library name to match the last component of the Bazel package. For example, a library stored at //foo/bar should be named bar, so it can be compiled with bazel build //foo/bar instead of bazel build //foo/bar:go_default_library. Tests would be named bar_test or bar_xtest.

We may want this to work differently in packages with a go_binary (sources have package main). For these packages, the go_binary name should match the package (again, so it can be compiled with //foo/bar). The library will need a different name. We may want to put sources and dependencies in go_binary instead of embedding a library if there are no tests.

Expose default attr 'compiler'

Not sure if this belongs here or in rules_go. I recently migrated from pubref rules (gogo) to a recent go_rules using this example: cortexproject/cortex@bazel-0.5.4...ianthehat:bazel-0.5.4

I had to make made gazelle generate go_proto_library rules with the compiler attribute set to my gogo_proto compiler.
I ran gazelle with -external=vendored -proto=default.

The only issue was in vendor/github.com/golang/protobuf/protoc-gen-go/descriptor/BUILD.bazel: The hacked up gazelle didn't set a different compiler for go_rpc_library but I think that would have fixed it. I just removed compiler and marked the file gazelle: ignore

My compiler had to use external @targets (those didn't specify the compiler attribute)

go_proto_compiler(                                                               
    name = "gogo_proto",                                                         
    deps = [                                                                     
        "@com_github_gogo_protobuf//gogoproto:go_default_library",               
        "//vendor/github.com/gogo/protobuf/proto:go_default_library",            
        "//vendor/github.com/gogo/protobuf/sortkeys:go_default_library",         
        "//vendor/github.com/gogo/protobuf/types:go_default_library",            
    ],                                                                           
    plugin = "@com_github_gogo_protobuf//protoc-gen-gogoslick",                  
    visibility = ["//visibility:public"],                                        
)

In order for the above to work I depend on external @targets. It's unclear if those targets are maintained by gazelle running with external=vendor. I think I would like gazelle to generate rules for external @targets using external=external mode and everything else using external=vendored mode.

Does that make sense?

Does it make sense to add args to gazelle:
--proto_compiler: default proto compiler to use when generating go_proto_library rules (default: @io_bazel_rules_go//proto:go_proto)
--rpc_proto_compiler: default proto compiler to use when generating go_rpc_library rules (default:
@io_bazel_rules_go//proto:go_grpc)

Thanks

Don't add dependencies on Well Known Types

(Migrated from bazelbuild/rules_go#944)

These are now carried by go_proto_compiler rules (since #1166), so Gazelle doesn't need to generate them.

Import path resolving does not always work

When a go_library embeds a go_proto_library gazelle sometimes picks the wrong one to use to resolve dependencies.

See google/gapid#1494 for a run where it did this in bulk

Gazelle doesn't know how to handle vendored proto deps

This is where I ran into it

https://github.com/grpc-ecosystem/grpc-gateway/tree/master/third_party/googleapis

We save a subset of the googleapi protos in third_party to insulate us from ustream changes.

Avoid generating tests in some directories

(Migrated from bazelbuild/rules_go#725)

Gazelle should support a directive (maybe # gazelle:donttest [subdir]) that suppresses generation of go_test rules in a subdirectory. This would be useful for vendor trees that don't include packages that are only needed by tests in vendor.

Gazelle should fix labels in rules in Bazel-native projects imported through Go-native vendoring

As Bazel is starting to get more popular, we're running into problems with Bazel-native Go projects that we import through Go-native vendoring (i.e. dep + the vendor/ directory).

An explicit example: kubernetes/repo-infra#54 imports github.com/bazelbuild/buildtools. The root BUILD.bazel file in bazelbuild/buildtools has a test_suite which makes sense in its repo:

test_suite(
    name = "tests",
    tests = [
        "//api_proto:api.gen.pb.go_checkshtest",
        "//build:go_default_test",
        "//build:parse.y.go_checkshtest",
        "//build_proto:build.gen.pb.go_checkshtest",
        "//deps_proto:deps.gen.pb.go_checkshtest",
        "//edit:go_default_test",
        "//extra_actions_base_proto:extra_actions_base.gen.pb.go_checkshtest",
        "//lang:tables.gen.go_checkshtest",
        "//tables:go_default_test",
        "//wspace:go_default_test",
    ],
)

but when imported into our repo, the labels are all wrong; they should instead be something like

test_suite(
    name = "tests",
    tests = [
        "//vendor/github.com/bazelbuild/buildtools/api_proto:api.gen.pb.go_checkshtest",
        "//vendor/github.com/bazelbuild/buildtools/build:go_default_test",
        "//vendor/github.com/bazelbuild/buildtools/build:parse.y.go_checkshtest",
        "//vendor/github.com/bazelbuild/buildtools/build_proto:build.gen.pb.go_checkshtest",
        "//vendor/github.com/bazelbuild/buildtools/deps_proto:deps.gen.pb.go_checkshtest",
        "//vendor/github.com/bazelbuild/buildtools/edit:go_default_test",
        "//vendor/github.com/bazelbuild/buildtools/extra_actions_base_proto:extra_actions_base.gen.pb.go_checkshtest",
        "//vendor/github.com/bazelbuild/buildtools/lang:tables.gen.go_checkshtest",
        "//vendor/github.com/bazelbuild/buildtools/tables:go_default_test",
        "//vendor/github.com/bazelbuild/buildtools/wspace:go_default_test",
    ],
)

Gazelle will already fix the go rules (I believe), but other things (like this test_suite) remain broken.

An (untested) naive idea is to have Gazelle or some other tool examine all labels in build rules under vendor/, adding the necessary path prefix if it's missing. I'm not sure how safe this is, and whether it'd work 100%, though.

Check minimum rules_go version

With #48, Gazelle generates build files that depend on the compilers attribute of go_proto_library, which was introduced after 0.8.1. We should check that the minimum version is at least 0.9.0.

This should be checked in the gazelle rule (error) and in Gazelle itself (warning).

Detect .go sources generated by custom rules and macros

(Migrated from bazelbuild/rules_go#654)

Gazelle currently detects .go files mentioned by name in the out and outs attributes of rules in BUILD files. This is helpful but incomplete. If a project uses a rule that implicitly produces a .go file or uses a macro that hides the .go file name, Gazelle won't see it and won't include the files.

One possible solution is to ask Bazel what sources are produces by all rules in a package. This could be done with bazel query or using a custom aspect. This process may be slow if the Bazel server is not already running, so it may not be appropriate to run this from an editor save hook.

Another approach would be to add some custom directive to Gazelle, telling it what the generated .go files will be for a rule or macro of a given name. This would be faster, but it would require some developer customization.

merger: attributes with multiple dictionaries are not kept

mergeExpr breaks an expression into a list and a dictionary (either of which may be empty) with exprListAndDict. This worked well before full multi-platform support was added, but now, generated expressions may have multiple select expressions, so this no longer works.

exprListAndDict will return an error when it encounters an expression it does not understand. When mergeRule gets this error, it will return the generated expression and discard the old expression, regardless of # keep comments.

Two things should be fixed:

exprListAndDict should be updated to handle expressions with generic, OS-specific, arch-specific, and platform-specific strings (it will need to inspect keys in select statements to do this). Each collection should be merged independently.
When exprListAndDict returns an error, mergeExpr should return the old expression if there are any # keep comments. Otherwise, it should return the generated expression. It should probably not return an error in any case.

Delete proto rules together or not at all

If Gazelle deletes a proto_library rule, it should also delete the go_proto_library rule in the same package that depends on it. If one cannot be deleted, the other must not be deleted.

Circular dependency in generated proto_library rules

In case a package contains multiple proto files:

these files have the same go_package option, and
some of these files are importing some others (no circular dependency)

gazelle will put them in the same proto_library rule with a dependency to itself. The generated go_proto_library will have the same issue.

Take google/api/{http,annotations}.proto for instance. They both have option go_package = "google.golang.org/genproto/googleapis/api/annotations;annotations", and annotations.proto imports http.proto. gazelle will generate the follow code:

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

proto_library(
    name = "annotations_proto",
    srcs = [
        "annotations.proto",
        "http.proto",
    ],
    visibility = ["//visibility:public"],
    deps = [
        ":annotations_proto",      <---------- CIRCULAR DEPENDENCY
        "@com_google_protobuf//:descriptor_proto",
    ],
)

go_proto_library(
    name = "annotations_go_proto",
    importpath = "google/api",
    proto = ":annotations_proto",
    visibility = ["//visibility:public"],
    deps = [
        ":go_default_library",      <---------- CIRCULAR DEPENDENCY
        "@com_github_golang_protobuf//protoc-gen-go/descriptor:go_default_library",
    ],
)

Don't recurse into directories referenced by local_repository

Bazel allows subdirectories within a workspace to be treated as external repositories with by referencing them with local_repository. This is useful for vendoring repositories that already have build files; import paths and labels within the vendored repository don't need to be updated.

Bazel automatically avoids building targets within these repositories. Gazelle should be aware of these repository rules and should avoid indexing and updating build files in these subdirectories.

Gazelle may not delete empty go_binary rules

Migrated from bazelbuild/rules_go#890

Gazelle deletes a rule if the only attributes left after merging are name and visibility. If you remove all binary sources, then add library sources and run Gazelle again, the go_binary rule will be left with importpath and library attributes.

Add, update, and remove repository rules

This is a catch-all issues for Gazelle repository rule management.

Gazelle will support an update-repos command. This will be able to:

Add, remove, or update a repository rule in WORKSPACE for a specific dependency.
Add repository rules for direct and transitive dependencies, based on import paths from Go libraries.
Update a set of repository rules (possibly all).
Remove repository rules for dependencies that aren't needed anymore.

Import repository rules from vendoring tools

(Migrated from bazelbuild/rules_go#1082)

Gazelle should be able to transcribe lock files from popular vendoring tools like dep into repository rules in WORKSPACE. These tools produce lock files, which contain import paths and commit ids for each remote repository. It should be straightforward to generate repository rules from these.

We should understand lock file formats of a few popular tools. dep will be first. Support for more tools can be added on demand.
The import functionality should be available via a new command. For example:

gazelle migrate-deps Gopkg.lock

Gazelle may initially add go_repository rules for imported dependencies. However, it is likely we will deprecate go_repository soon, so Gazelle should add git_repository and http_archive rules with pre-generated build files.
- There isn't a viable replacement for go_repository yet. new_git_repository and new_http_archive only accept a single flat build file, which can be difficult to maintain and causes migration problems for repositories that eventually migrate to Bazel. We need replacements for these rules that can overlay a tree of build files on a downloaded repository.
Gazelle should not add new rules if an existing rule checks out the same repository. The import command must be idempotent. If dependencies change or are updated in the lock file, Gazelle should update rules in place when possible (and report an error otherwise).
Gazelle may not be able to remove dependencies that were removed from the lock file.

prefix should not be mandatory in gazelle rule

The prefix attribute is passed to the Gazelle binary on the command line with the -go_prefix flag. This flag is not mandatory; Gazelle can read the prefix from # gazelle:prefix directives. Since the flag is not mandatory, the attribute should not be mandatory.

This is needed for compatibility with the gazelle macro in rules_go.

update-repos should be able to update io_bazel_rules_go

It's not a normal Go repository, but Gazelle should provide a simple way to update it.

When this is supported, the version check should print the command needed to perform the update instead of telling users to update their WORKSPACE manually.

Add rules to index after pre-resolve merge

resolve.RuleIndex provides two public methods that basically do the same thing: AddRulesFromFile and AddGeneratedRules. These methods need to account for naming conflicts between generated rules and existing rules.

Instead, we should just have one method that indexes the rules in a file after the pre-resolve merge has been performed. The pre-resolve step will combine generated and existing rules and will delete empty rules.

This should also simplify merger.MergeFile, which currently returns a list of merged rules to be passed to AddGeneratedRules.

For Proto files, use go_proto_library or go_grpc_library instead of go_library

Current Behavior

To create a BUILD file for protobuf, Gazelle is generating a go_library rule that has a go_grpc_library or go_proto_library as dependency. Then, to use the protobuf BUILD as a dependency from another BUILD, Gazelle is using that go_library rule.

Problems with Current Behavior

Creating a go_library rule is not necessary, because go_grpc_library and go_proto_library rules can be used directly as dependencies from external BUILD files.
If we have multiple proto files in one folder, Gazelle is failing, because just one go_library called go_default_library is created, so just that dependency can be used from another BUILD.

Proposed Behavior

Avoid creating go_library rules for protos.
Using go_grpc_library or go_proto_library as dependencies from external BUILDs files.

Add output mode for verification

(Migrated from bazelbuild/rules_go#692)

Per discussion in #688, in addition to -mode=print,fix,diff, Gazelle should have an output mode where it exits successfully (code 0) if all files are up to date and unsuccessfully (code 1) if there are differences. It may print a list of differing files.

This could be used in a gazelle_test rule, which would be useful as a presubmit.

Rename output modes

(Migrated from bazelbuild/rules_go#693)

Gazelle -mode=fix is confusingly similar to the recently added fix command. I'd like to rename -mode to -output_mode and -mode=fix to -output_mode=write.

To ease the transition, -mode and -mode=fix will continue to work as aliases for the new names, printing warnings when used. The old names can be removed in a few months.

Index build files in external repositories

(Migrated from bazelbuild/rules_go#606)

Gazelle currently builds an index of libraries in the current repository and uses it to resolve dependencies. We should expand this to cover libraries in external repositories.

Bazel holds a directory for each external repository that has been fetched within its cache directory. We should index these directories, rather than checking out repositories separately, since extra checkouts are expensive, and we need to avoid reproducing Bazel logic to generate or replace build files (i.e., go_repository or something similar). We won't attempt to index repositories that haven't been fetched by Bazel.

Support multiple packages in the same directory

(Originally bazelbuild/rules_go#315)

We should consider supporting projects with multiple Go packages in the same directory. "go build" does not allow this, but it is fairly common within Google, and some projects being open-sourced by Google have expressed interest in this.

#5 (naming rules after Go packages) is probably a prerequisite.

Delete rules which are empty except for deps

Gazelle merges rules in two separate phases: an early phase for all attributes except deps, and a late phase for deps only.

The merger deletes rules which are named in the empty list if, after merging, they have no attributes other than name and visibility.

Deletion is only performed in the first merge phase.

This means that rules that are empty except for deps will not be deleted.

Gazelle uses the wrong naming convention for go_grpc_library

For a grpc proto files gazel generates the following build target:

go_grpc_library(
    name = "helloworld_go_proto",
    importpath = "builds/examples/protobuf",
    proto = ":helloworld_proto",
    visibility = ["//visibility:public"],
)

However, I believe the standard for naming is <proto file name>_<lang>_grpc, thus this should be:

go_grpc_library(
    name = "helloworld_go_grpc",
    importpath = "builds/examples/protobuf",
    proto = ":helloworld_proto",
    visibility = ["//visibility:public"],
)

Fyi, this seems to correctly work when the file only contains a grpc service definition without any messages definitions.

Binaries don't always need a library

(Migrated from bazelbuild/rules_go#585)

Gazelle always generates a library and then a binary that consumes it.
This is not often wanted or needed, better to just generate a binary directly unless there is also a test.

Related to #5

Detect and update rules in non-standard layouts

(Migrated from bazelbuild/rules_go#746)

We have examples in this repository that are in non standard directory layouts (see examples/cgo/sub).
It would be good if gazelle automatically spotted these and knew what to do, at the moment you have to add ignore directives, and gazelle will not update the rule for you.

Duplicated dependency in Gazelle generated BUILD.bazel

My project has go-iatty as a dependency. When building using gazelle generated BUILD files I get the following error:

ERROR: /Users/kkiningh/go/src/ci/vendor/github.com/mattn/go-isatty/BUILD.bazel:3:1: Label '//vendor/golang.org/x/sys/unix:go_default_library' is duplicated in the 'deps' attribute of rule 'go_default_library'
ERROR: /Users/kkiningh/go/src/ci/vendor/github.com/gin-gonic/gin/BUILD.bazel:3:1: Target '//vendor/github.com/mattn/go-isatty:go_default_library' contains an error and its package is in error and referenced by '//vendor/github.com/gin-gonic/gin:go_default_library'

Looking at the generated build rules, I see the following declaration

go_library(                                                                                                                                                                                                     
    name = "go_default_library",                                                                                                                                                                                
    srcs = [
        # omitted
    ],
    importpath = "github.com/mattn/go-isatty",
    visibility = ["//visibility:public"],
    deps = select({
        "@io_bazel_rules_go//go/platform:solaris": [
            "//vendor/golang.org/x/sys/unix:go_default_library",
        ],
        "//conditions:default": [],
    }) + select({
            "@io_bazel_rules_go//go/platform:linux_ppc64": [
            "//vendor/golang.org/x/sys/unix:go_default_library",
        ],
        "@io_bazel_rules_go//go/platform:linux_ppc64le": [
            "//vendor/golang.org/x/sys/unix:go_default_library",
        ],
        "//conditions:default": [],
    }),
)

I'm not sure why this would cause a duplicated dependency, but when I remove the entire dep declaration the build proceeds file. I'm building on OSX High Sierra with Intel i7.

Extract canonical import path from .go files

Migrated from bazelbuild/rules_go#874

See https://golang.org/doc/go1.4#canonicalimports

Go implementation: findImportComment

Insert load statements in a better place

When we need to insert new load statements in a build file, we should look for a better place to insert them.

If there is an existing block of load statements, add to that block. If the statements there are sorted (by .bzl file label), insert in sorted order. Otherwise, insert at the end.

If there is no existing block of load statements, insert after leading comments in the file, before any rules.

Unable to run gazelle: no such attribute 'constraint_values' in 'config_setting' rule

Empty project. Only WORKSPACE and bazel.BUILD.

WORKSPACE

http_archive(
    name = "io_bazel_rules_go",
    url = "https://github.com/bazelbuild/rules_go/releases/download/0.8.1/rules_go-0.8.1.tar.gz",
    sha256 = "90bb270d0a92ed5c83558b2797346917c46547f6f7103e648941ecdb6b9d0e72",
)
load("@io_bazel_rules_go//go:def.bzl", "go_rules_dependencies", "go_register_toolchains")
go_rules_dependencies()
go_register_toolchains()

http_archive(
    name = "bazel_gazelle",
    url = "https://github.com/bazelbuild/bazel-gazelle/releases/download/0.8/bazel-gazelle-0.8.tar.gz",
    sha256 = "e3dadf036c769d1f40603b86ae1f0f90d11837116022d9b06e4cd88cae786676",
)
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies")
gazelle_dependencies()

BUILD.bazel

load("@bazel_gazelle//:def.bzl", "gazelle")

gazelle(
    name = "gazelle",
    prefix = "github.com/prestonvanloon/casper",
)

bazel run //:gazelle

Loading: 
Loading: 0 packages loaded
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:android: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:darwin: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:dragonfly: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:freebsd: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:nacl: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:netbsd: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:openbsd: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:plan9: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:solaris: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:windows: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:amd64p32: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:arm64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:mips: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:mips64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:mips64le: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:mipsle: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:ppc64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:ppc64le: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:s390x: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:android_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:android_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:android_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:android_arm64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:darwin_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:darwin_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:darwin_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:darwin_arm64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:dragonfly_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:freebsd_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:freebsd_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:freebsd_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_arm64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_mips: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_mips64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_mips64le: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_mipsle: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_ppc64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_ppc64le: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:linux_s390x: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:nacl_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:nacl_amd64p32: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:nacl_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:netbsd_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:netbsd_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:netbsd_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:openbsd_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:openbsd_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:openbsd_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:plan9_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:plan9_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:plan9_arm: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:solaris_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:windows_386: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/io_bazel_rules_go/go/platform/BUILD.bazel:12:1: @io_bazel_rules_go//go/platform:windows_amd64: no such attribute 'constraint_values' in 'config_setting' rule
ERROR: /home/preston/.cache/bazel/_bazel_preston/29c8e4b95d018b0f35a1d433da379eb0/external/go_sdk/BUILD.bazel:14:1: Target '@io_bazel_rules_go//go/platform:darwin_amd64' contains an error and its package is in error and referenced by '@go_sdk//:host_tools'
ERROR: Analysis of target '//:gazelle' failed; build aborted
INFO: Elapsed time: 0.447s
FAILED: Build did NOT complete successfully (0 packages loaded)
ERROR: Build failed. Not running target

Associate default prefixes with external repositories

(Migrated from bazelbuild/rules_go#606)

We should associate prefixes with external repository names. These prefixes would be used transform import paths to Bazel labels for repositories that haven't been fetched and can't be indexed yet (see #12).

In the examples below, we would transform dependencies on github.com/example/project to @repo_with_custom_name//:go_default_library.

For go_repository, we can infer this from importpath or remote.

go_repository(
    name = "repo_with_custom_name",
    importpath = "github.com/example/project",
)

We may be able to do this for git_repository, too, in some cases.

git_repository(
    name = "repo_with_custom_name",
    remote = "https://github.com/example/project",
)

This wouldn't work with import path redirection. In particular, it wouldn't work with golang.org, gopkg.in, any fork, or private repositories. Gazelle should recognize directives in WORKSPACE to override the import path.

# gazelle:importpath github.com/example/project
git_repository(
    name = "repo_with_custom_name",
    remote = "https://github.com/fork/project",
)

If Gazelle can't discover the repository by parsing WORKSPACE (i.e., if a repository is declared in a macro), we should be able to read standalone declarations that map the prefix to the repo name.

# gazelle:importpath repo_with_custom_name github.com/example/project

Fix command should explain what's wrong

Migrated from bazelbuild/rules_go#792

When a BUILD file needs to be fixed, gazelle fix just emits a warning without explaining what's wrong with it. This could be something as trivial as loaded symbols being out of order.

Our warning should explain what needs to be fixed. We should not emit a warning for trivial problems that won't interfere with later operations (loaded symbol ordering).

Fix gazelle rule in root build files

Gazelle should automatically migrate users from the old gazelle macro (in @io_bazel_rules_go//go:def.bzl) to the new gazelle rule (in @bazel_gazelle//:def.bzl). The old macro should refer to the new Gazelle, so this should mostly happen automatically.

Allow wrappers

Migrated from bazelbuild/rules_go#748

Allow people to mark rules as a wrapper for a go rule, so they can be managed by gazelle as if the were the underlying rule.
It would be even nicer if you could do this once for an entire rule type rather than per rule. The original example was bazelbuild/rules_docker#119 where go_image is a proxy for go_binary as far as gazelle should be concerned.

Generate go_proto_library with gRPC plugin

We currently generate either go_proto_library or go_grpc_library, depending on whether .proto files have service declarations. go_grpc_library is now just a wrapper on go_proto_library with the grpc plugin, so we should generate that instead. We'll need to migrate existing instances.

We should avoid merging the compiler attribute in proto rules, since developers can set this to something else manually.