Open roey-e opened 4 years ago
hmm i'm pretty sure that worked in the past. I'll try to reproduce this on my machine later.. @njlr do you think there was a breaking API change in Buck or Buckaroo?
According to the Bazel docs:
Arguments must be string literals (no variable) and load statements must appear at top-level, i.e. they cannot be in a function body.
So we cannot use function outputs or variables in a load
.
The reason the actual workspace name has a weird hash appended is to ensure that even when there are two different versions of the same package somewhere in the resolution tree there is not a name collision.
I will have to think further about how this might work.
I'm not getting something. The package which contains buckaroo_setup
is generated? Who generates it?
@errangutan
I'm not getting something. The package which contains
buckaroo_setup
is generated? Who generates it?
Buckaroo is a tool that fetches packages containing Buck or Bazel projects. It downloads them to a folder local to the project (a bit like node_modules
) and also generates a set of macros for the user to use in their own BUILD
files. Buckaroo solves the transitive workspace dependency problem for Bazel.
Buckaroo packages are usually identified by a name like github.com/someorg/someproject
. However, it is possible to depend on two different versions of one package, so the workspace names, which must be globally unique to satisfy Bazel, have a hash appended like this:
package name -> workspace name
github.com/someorg/someproject -> github_someorg_someproject_aabbccdd
The challenge now is that the user wants to load a macro from a package. We can get the workspace name using a function generated by Buckaroo:
load("//buckaroo:defs.bzl", "buckaroo_workspace")
someproject_workspace = buckaroo_workspace("github.com/someorg/someproject")
someproject_workspace # github_someorg_someproject_aabbccdd
But we cannot use this variable in a load
:
# Not allowed
load(someproject_workspace, "my_macro")
Perhaps you can give some insight into how we can achieve this in Bazel?
I've given this some thought and I don't think this is possible. I am by no means an expert on Bazel so take this with a grain of salt. I would personally open a feature request and discuss this with the Bazel team. In you current stage, do you simply have the required version hardcoded in the load statement?
@nikhedonia Another option to consider is to add a "cell_name"
option to dependencies in the manifest. Users can then be guaranteed that this name will be used for the cell containing the macros. Buckaroo would have to check that these are globally unique, of course. Advantage of this approach is that we don't need any changes from Buck / Bazel, and I think their reasons for not allowing variables in load
statements are good.
Description
My goal is to use macros defined in a dependency's "bzl" file. This is even more useful when using Bazel, as Bazel provides custom rules in addition to macros.
From my understanding, labels of buckaroo cells should be use with the buckaroo macros and not written explicitly.
In Bazel mode, some hash is added to the workspaces' names. This makes the use of the macros mandatory.
The problem here is that the load statement in Buck and in Bazel accept string literal only.
Examples: In Buck:
In Bazel:
Expected Behavior
Is there a proper way for loading macros with Buckaroo? How can I make it work?
Actual Behavior
In Buck:
In Bazel:
Context
Specifically, I'm trying to use protobuf's "proto_gen" rule/macro.
Your Environment