Decide whether to eliminate the prelude_bazel file

[brandjon]

(See also previous discussion in #1674 and #3835.)

Separate from the issue of how the prelude file is technically loaded (#11940), and whether it should be restricted to only contain load() statements, we need to decide whether we want to eventually eliminate it altogether. That is, we need to decide if it's a good idea to allow users to customize the set of predeclared symbols in their BUILD files.

I recently learned that my strongest objection to the prelude doesn't apply anymore: I was worried about the prelude file leading to repos not being composable, but it turns out that so was everyone else, so now the prelude only applies within the repo where it's defined (#3991).

So the remaining arguments against the prelude are:

• It's harder to read and understand BUILD files without any context on the repo you're looking at (spooky action at a distance).
• Changes to the prelude, or its transitive dependencies, trigger reevaluation of every package. That is, it encourages unnecessary (implicit) load() dependencies.

The argument in favor of keeping it is that it's convenient, and allows you to put Starlark rules on the same footing as native rules in terms of their implicit availability in the BUILD environment.

[alandonovan]

The argument in favor of keeping it is that it's convenient, and allows you to put Starlark rules on the same footing as native rules in terms of their implicit availability in the BUILD environment.

The way to put every rule on the same footing is to require that each is explicitly loaded from a .bzl file, even if their implementation is currently built-in. Isn't that a goal of all our Starlarkification efforts? If we could wave a wand and replace every implicit use of a native rule by an explicit load statement for that rule, wouldn't we do that?

The other argument for keeping it is that some users are already depending on it (see #11940 (comment)) as a hook for adding common behavior to every package. Convenient though it may be, I would argue that it is an abuse of an undocumented implementation detail (see #1674) and another form of spooky action at a distance. The specific use-case described in the latter issue could be addressed adding an explicit macro call at the bottom of every BUILD file. (This might make the macro simpler and more flexible as the rules would then exist at the time of the call.)

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!