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
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.
(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.
(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.
(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
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
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.
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:
WORKSPACEBUILD.bazelsrc/main.goWORKSPACE:
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"],
)
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.
(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.
(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.
(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.
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).
(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.
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?
(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).
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 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.
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.
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.
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.
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.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.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.
(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 should:
bazel run //:gazellebazel build a newly generated go_binary rule.This test should work similarly to rules_go integration tests (see bazel_tests.bzl).
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.
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
(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
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
In case a package contains multiple proto files:
go_package option, andgazelle 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",
],
)
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.
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.
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
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
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).
(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.
(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.
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.
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.
This is a catch-all issues for Gazelle repository rule management.
Gazelle will support an update-repos command. This will be able to:
(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.
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.
Migrated from bazelbuild/rules_go#874
See https://golang.org/doc/go1.4#canonicalimports
Go implementation: findImportComment
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.
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.go_library called go_default_library is created, so just that dependency can be used from another BUILD.go_library rules for protos.go_grpc_library or go_proto_library as dependencies from external BUILDs 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.
(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.
gazelle migrate-deps Gopkg.lock
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.
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.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.
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.
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.
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.
(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.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.