loads in //build/bazel/remote/execution/v2 induce dependencies #78
Comments
|
Something odd is going on here -- for example, I have a my own fork of tools_remote https://github.com/ola-rozenfeld/tools_remote/blob/tool/WORKSPACE which depends on remote-apis but doesn't have rules_go as a dependency, yet it compiles just fine. |
|
Disregard, I reproduced it. Java builds are failing without rules_go. Will look into this. |
|
I introduced the go_rules dependency. I'll look into this and try to fix it so that manual users don't need to include it. |
|
My plan is to use the same solution as https://github.com/googleapis/googleapis, which provides an workspace initialization function that allows you to specify which languages you want: https://github.com/googleapis/googleapis/blob/master/WORKSPACE#L11 It supplies default no-op implementations of rules for languages you aren't using. |
jasharpe
pushed a commit
to jasharpe/remote-apis
that referenced
this issue
May 23, 2019
…he rules of languages they actually use. We reuse the solution developed for googleapis, see "switched_rules_by_language": https://github.com/googleapis/googleapis/blob/master/repository_rules.bzl Basically the way this works is that we generate a Bazel repository that wraps the enabled language rules, and implements them as no-ops if they are not specifically enabled. Fixes bazelbuild#78.
jasharpe
pushed a commit
to jasharpe/remote-apis
that referenced
this issue
May 23, 2019
…he rules of languages they actually use. We reuse the solution developed for googleapis, see "switched_rules_by_language": https://github.com/googleapis/googleapis/blob/master/repository_rules.bzl Basically the way this works is that we generate a Bazel repository that wraps the enabled language rules, and implements them as no-ops if they are not specifically enabled. Fixes bazelbuild#78.
jasharpe
pushed a commit
to jasharpe/remote-apis
that referenced
this issue
May 23, 2019
…he rules of languages they actually use. We reuse the solution developed for googleapis, see "switched_rules_by_language": https://github.com/googleapis/googleapis/blob/master/repository_rules.bzl Basically the way this works is that we generate a Bazel repository that wraps the enabled language rules, and implements them as no-ops if they are not specifically enabled. I've tested with with tools_remote, and builds there now work when this snippet is added to the workspace, even without adding go workspace dependencies: ``` load("@remoteapis//:repository_rules.bzl", "switched_rules_by_language") switched_rules_by_language( name = "bazel_remote_apis_imports", java = True, ) ``` Fixes bazelbuild#78.
jasharpe
pushed a commit
to jasharpe/remote-apis
that referenced
this issue
May 23, 2019
…he rules of languages they actually use. We reuse the solution developed for googleapis, see "switched_rules_by_language": https://github.com/googleapis/googleapis/blob/master/repository_rules.bzl Basically the way this works is that we generate a Bazel repository that wraps the enabled language rules, and implements them as no-ops if they are not specifically enabled. I've tested with with tools_remote, and builds there now work when this snippet is added to the workspace, even without adding go workspace dependencies: ``` load("@remoteapis//:repository_rules.bzl", "switched_rules_by_language") switched_rules_by_language( name = "bazel_remote_apis_imports", java = True, ) ``` Fixes bazelbuild#78.
jasharpe
pushed a commit
to jasharpe/remote-apis
that referenced
this issue
May 23, 2019
…he rules of languages they actually use. We reuse the solution developed for googleapis, see "switched_rules_by_language": https://github.com/googleapis/googleapis/blob/master/repository_rules.bzl Basically the way this works is that we generate a Bazel repository that wraps the enabled language rules, and implements them as no-ops if they are not specifically enabled. I've tested with with tools_remote, and builds there now work when this snippet is added to the workspace, even without adding go workspace dependencies: ``` load("@remoteapis//:repository_rules.bzl", "switched_rules_by_language") switched_rules_by_language( name = "bazel_remote_apis_imports", java = True, ) ``` Fixes bazelbuild#78.
ola-rozenfeld
pushed a commit
that referenced
this issue
May 24, 2019
…he rules of languages they actually use. (#81) We reuse the solution developed for googleapis, see "switched_rules_by_language": https://github.com/googleapis/googleapis/blob/master/repository_rules.bzl Basically the way this works is that we generate a Bazel repository that wraps the enabled language rules, and implements them as no-ops if they are not specifically enabled. I've tested with with tools_remote, and builds there now work when this snippet is added to the workspace, even without adding go workspace dependencies: ``` load("@remoteapis//:repository_rules.bzl", "switched_rules_by_language") switched_rules_by_language( name = "bazel_remote_apis_imports", java = True, ) ``` Fixes #78.
santigl
pushed a commit
to santigl/remote-apis
that referenced
this issue
Aug 26, 2020
This is intended for derived clients that provide extra services. Allows to unblock internal refactoring for bazelbuild#78.
santigl
pushed a commit
to santigl/remote-apis
that referenced
this issue
Aug 26, 2020
Prepares for addition of a second connection to the CAS service in DialParams (bazelbuild#78). Also adding better named overloads for constructors in order to migrate users to these names.
santigl
pushed a commit
to santigl/remote-apis
that referenced
this issue
Aug 26, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The loads of grpc and rules_go starlark methods mandate that any workspace that references the //build/bazel/remote/execution/v2 package - even to non-language targets - provide both the rules_go and grpc repositories. This will break implementors that do not have these dependencies already, and require that wholly unrelated implementations (i.e. buildfarm in Java) include declarations for these go and grpc repos, that must match by name.
If remote-apis is going to continue down this path of providing language implementations (C++ and go so far), it should provide an extension library for initializing the repo with these dependencies activated, and personally I would like to have these available in separate packages by language, if only to make it possible not to import the growing list of supported language rules toolchains.
The text was updated successfully, but these errors were encountered: