Mandatory load() statements in BUILD files

Lukács T. Berki

unread,

Feb 10, 2020, 7:43:25 AM2/10/20

to bazel-discuss

Hey there,

How to go about requiring mandatory load() statements for built-in rules in BUILD files?

We eventually want to have all our rules in Starlark and loading all rules that are now built into Bazel (cc_*, java_*, sh_*, etc.) is a precondition to that. Unfortunately, it's also a pretty intrusive change, requiring changes to every BUILD file.

We already have --incompatible_* flags for Java and C++ (--incompatible_load_{java,cc}_rules_from_bzl}, flipping which would be very destructive at the moment. What next?

We could provide a tool that updates all BUILD files in a repository (and maybe integrate it into Buildifier), announce a release to flip the flags, then flip them as planned and do it for every built-in rule at the same time to minimize the pain. Alternatively, we could do a test run with a moderately used rule first (e.g. proto_library) to see where the rough spots are, although that would require *two* incompatible releases instead of one.

If this absolutely does not work, we could in theory "pretend" that these .bzl files are loaded for every BUILD file just like we "pretend" that some repositories are declared in WORKSPACE files, although that would be somewhat sad because then these rules would need to be special forever.

--

Lukács T. Berki | Software Engineer | lbe...@google.com |

Gunnar Wagenknecht

unread,

Feb 10, 2020, 8:02:48 AM2/10/20

to "Lukács T. Berki", bazel-discuss

> On Feb 10, 2020, at 04:43, 'Lukács T. Berki' via bazel-discuss <bazel-...@googlegroups.com> wrote:
> We could provide a tool that updates all BUILD files in a repository (and maybe integrate it into Buildifier), announce a release to flip the flags, then flip them as planned and do it for every built-in rule at the same time to minimize the pain.

+1 for a tool.

The approach I saw at BazelCon and which I took as a recommended best practice is to have a single load statement in *every* BUILD file which loads a "default" file with all the other load statements (and potentially some macros).

Having it in every BUILD file makes this behavior explicit but is also error prone. Perhaps one could declare default "loads" via the .bazelrc file?

-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/

Yannic

unread,

Feb 10, 2020, 8:55:00 AM2/10/20

to bazel-discuss

Tooling for --incompatible_load_{cc,java,proto,python}_rules_from_bzl is already available. Running "buildifier --lint=fix --warnings=native-cc,native-java,native-proto,native-py -r ." in your workspace should add load() statements to all BUILD (and .bzl) files. I know that at least the tracking bug for rules_proto mentions this, maybe the other bugs should be updated?

Alternatively, I've recently learned about the (undocumented?) "//tools/build_rules/prelude_bazel", which seems to allow implicitly adding load() statements to every BUILD file (although, AAICT, that's not fixing uses of native.cc_library & friends). I'd advocate for using the buildifier fix and going the explicit route, though.

I'm definitely in favor of requiring the load() statements in every BUILD and .bzl file. Having them implicitly loaded probably means that releases of rules_{cc,java,proto,python} are still closely coupled to Bazel releases. Wasn't part of the motivation to allow rules to evolve independently of Bazel? I'm also unsure what the implicit loads would mean for native.cc_library.

Lukács T. Berki

unread,

Feb 10, 2020, 11:18:41 AM2/10/20

to Yannic, bazel-discuss

Hey there,

The problem with a per-repository prelude is that that still needs an explicit change to the repository and given the simplicity of the change, we could just then change the BUILD files. We could go the "built-in prelude route" at the cost of these rules being special forever. I was hoping to avoid that -- both due to the "better explicit than implicit" principle and to avoid the "BUILD files coupled to the Bazel release" problem Yannic mentioned.

I'm not very partial to loading one .bzl file or one per language. My initial inclination was to do one per language and avoid an extra level of indirection.

@Yannic: yes, we want to move the rules out of the Bazel binary at some point, but that requires figuring out what to put in the WORKSPACE file and how to make that change in addition to figuring out the same for BUILD files and in the meantime, I was hoping we could get by by distributing the .bzl files within Bazel in the meantime and start working on rewriting the rules.

Yes, unfortunately, native.cc_library() and the like will have to be changed. It looks like something that can be mostly automated.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/de907a56-896b-4c22-b4e5-5c8704c5ac8c%40googlegroups.com.

Lukács T. Berki

unread,

Feb 11, 2020, 9:17:16 AM2/11/20

to Yannic, gun...@wagenknecht.org, bazel-discuss, Laurent Le Brun

Since I haven't heard very strong objections, I prepared a document:

https://docs.google.com/document/d/1UwgGtsWZRJxXewLCoqf1zD1Y_houN1ldwZpQ4xdoAa4/

and a pull request to the proposals repository:

https://github.com/bazelbuild/proposals/pull/170

Lukács T. Berki

unread,

Mar 10, 2020, 5:11:35 AM3/10/20

to Yannic, Gunnar Wagenknecht, bazel-discuss, Laurent Le Brun

Update: after thinking about this a while, I wrote up an alternative that allows us to migrate the native rules to Starlark without very intrusive mandatory changes.

Please take a look:

https://docs.google.com/document/d/1k35978IH0T3l7fktt08X21fRLu6cVn6bPUUPmOpN80Q/edit#

Lukács T. Berki

unread,

Mar 27, 2020, 9:50:14 AM3/27/20

to Yannic, Gunnar Wagenknecht, bazel-discuss, Laurent Le Brun, Philipp Wollermann, Alan Donovan, Jon Brandvein

I wrote up an explicit plan based on the feedback to the above two documents:

https://docs.google.com/document/d/16pZO_Ca8EVmaF8mvl_Ugbeapn5gBjRcAqOwjprRP6NY

Please take a look! It's short, only ~400 words.

xavibon...@gmail.com

unread,

Apr 2, 2020, 3:22:34 PM4/2/20

to bazel-discuss

For the migration of cc_rules using buildifier worked for me like a charm. Good job!

El divendres, 27 març de 2020 14:50:14 UTC+1, Lukács T. Berki va escriure:

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/de907a56-896b-4c22-b4e5-5c8704c5ac8c%40googlegroups.com.

--
Lukács T. Berki | Software Engineer | lbe...@google.com |

Google Germany GmbH | Erika-Mann-Str. 33 | 80636 München | Germany | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

Reply all

Reply to author

Forward