BUILD- and WORKSPACE-loaded bzl files should have the same predeclared environment

[brandjon]

A .bzl file should define the same set of top-level symbols regardless of whether it was loaded on behalf of a BUILD file or WORKSPACE file. Today, the set of symbol names is the same, but the native modules of the two bzl types are different.

We want to avoid spurious differences between types of bzls files, both for the sake of simplicity and to be friendlier to tooling. Clearly there are features that do not apply to both contexts -- native.glob() makes no sense during WORKSPACE evaluation, and native.register_toolchains makes no sense during BUILD evaluation. But we can address this by failing at evaluation time if called from the wrong context. We already do that, for instance, if native.glob() is called at the top level in a bzl file rather than inside a macro.

Arguably we can also have BUILD and WORKSPACE files themselves share the same environment. But if we do that, let's track it in a separate bug.

@alandonovan

[alandonovan]

Agreed. One benefit is that the set of predeclared names is an input to the Starlark resolver (and thus compiler), so different names mean the .bzl file must be compiled differently.

[brandjon]

so different names mean the .bzl file must be compiled differently.

Note that the set of names is currently the same (and there's a test to ensure it remains the same).

Deprioritizing this issue because the benefit is mostly aesthetic, and will become irrelevant as we migrate from the current repository mechanism to bzlmod.

[Wyverald]

Discussed with @brandjon yesterday:

• we want binding names to be the same across all three bzl environments (BUILD-loaded, WORKSPACE-loaded, and Bzlmod-loaded)
  • this is so that the same .bzl file can be used by all three environments without erroring outright (this is not necessarily a desired feature, but somewhat nice since the file extensions are all .bzl)
• we don't necessarily want the same binding name to point to the same object (enforcing this tends to cause an if at the top of the bound function anyway)
• we don't want to enforce identical fields under the native object for the three bzl environments (so using native.cc_library in a WORKSPACE-loaded bzl file should simply result in a "field not found" error)
  • Right now native.cc_library is defined for a WORKSPACE-loaded bzl file, but errors as soon as it's invoked. This is not better than just having it be absent under native. Changing this is only visible for those who use dir(native), which is ridiculous in the first place.

[fmeum]

@brandjon Is it possible that repository_rule is a further difference that is not caught by

bazel/src/test/java/com/google/devtools/build/lib/packages/BazelStarlarkEnvironmentTest.java

Line 59 in 968422d

public void buildAndWorkspaceBzlEnvsDeclareSameNames() throws Exception {

?

[brandjon]

We discussed this again more recently. We confirm that there's conceptually only one .bzl dialect, but that the native object is currently magical because its fields depend on the context. We'd like to simplify by merging all the native variants into a single object, whose fields may error out if called in the wrong context.

This is basically the same as what happens today if you try to glob in WORKSPACE context, or instantiate a repo rule in BUILD context. (Some of those may actually currently be crash bugs, in fact.) The only observable difference will be dir/hasattr behavior, which, aside from change detector tests, will only break users who are trying to determine whether they are in BUILD or WORKSPACE context. We think that usage is rare...

Is it possible that repository_rule is a further difference that is not caught by

No, I don't think so. I believe all non-native objects in the top-level environment are treated the same. Even native should be covered by that test.

[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. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[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!