Parsing of the WORKSPACE file should be consistent with other parsing contexts

Description of the problem / feature request:

The WORKSPACE file is parsed with a different context to other files. Notably, it’s possible to mingle load and other function calls together. The same is not true of files loaded into the WORKSPACE. This makes modularising the WORKSPACE a taxing problem, littered with boilerplate as we try and avoid this inconsistency.

Feature requests: what underlying problem are you trying to solve with this feature?

As an example, Bazel Federation requires someone to load the repositories, then call a function, then load another file, then call another function:

load("@bazel_federation//:repositories.bzl", "rules_java")
rules_java()
load("@bazel_federation//setup:rules_java.bzl", "rules_java_setup")
rules_java_setup()

A similar pattern needs to be followed for people attempting to modularise any WORKSPACE file.

This approach is repetitious and filled with boilerplate, and should really be:

load("@bazel_federation//setup:rules_java.bzl", "rules_java_setup")
rules_java_setup()

Where rules_java_setup first of all loads the respositories.bzl and calls rules_java().

As another example, using maybe in a file that is loaded (but outside of a function) is unsupported, so conditional loading of repositories and subsequent calls to functions defined within those repos is unsupported.

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Use Bazel Federation and boggle at the boilerplate.

What’s the output of bazel info release?

0.29.0

Have you found anything relevant by searching the web?

Issues that relate to this:

#1550 If load worked within a function, this problem could be mitigated.

#1943 Recursive WORKSPACE loading would allow a clunky and inelegant solution to be implemented.

Any other information, logs, or outputs that you want to share?

I realise that someone is going to suggest the rationale for closing #1550 is still valid. On a technical level, I can buy that for now, but I think that the usability impact of this decision on Bazel users is growing, and as adoption spreads will continue to grow worse. Providing a solution to modularising WORKSPACE files in a way that minimises boilerplate is going to be crucial to enabling a pleasant developer experience.

[philwo]

@keith I don’t think we’ll add recursive workspaces or any other new features to the WORKSPACE file parsing. Instead, we’re aiming for the WORKSPACE file to be a flat namespace and prevent any transitive loading in the future (like the current deps.bzl pattern). Ideally, we can then also remove all current HTTP, Git, etc. repository features from Bazel and only leave the “local repository”.

Instead, the complexity of recursive / transitive dependency resolution, clean modularization and downloading modules from various sources will be solved via the new external tool bzlmod, which will generate a flat WORKSPACE file and handle downloads.

The design for that is here: https://groups.google.com/g/bazel-dev/c/6TEyoGb9ys0 - please comment on the doc if you think this doesn’t address your requirements! 😊

[hicksjoseph]

Thanks much Xudong. I will follow up with Simon directly if he has any questions.