bazel 7.0.2 build with --noenable_bzlmod still produce MODULE.bazel file

[jacobmou]

Description of the bug:

We adopted bazel 7.0.2 in our code repo and disable bzl_mod in the root bazelrc file like

always --noenable_bzlmod

However, we are getting many user reports mention their builds still produce MODULE.bazel and/or MODULE.bazel.lock files sporadically. We have not find a way to reproduce the issue yet.

Which category does this issue belong to?

Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

Ubuntu 22.04

What is the output of bazel info release?

release 7.0.2-2-g4d9c49e5a4-aurora

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

we backported fix in 52adf0b.

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

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

No response

[meteorcloudy]

Hmm, I'm not able to reproduce this

pcloudy@pcloudy-macbookpro3:~/workspace/my_tests/empty_workspace (master), (bazel 7.0.2)
$ ls
BUILD     WORKSPACE main.cc
pcloudy@pcloudy-macbookpro3:~/workspace/my_tests/empty_workspace (master), (bazel 7.0.2)
$ bazel build //:bin
Starting local Bazel server and connecting to it...
INFO: Invocation ID: 878b026a-712d-4cd5-b326-271b60776ce9
INFO: Reading rc options for 'build' from /Users/pcloudy/workspace/my_tests/empty_workspace/.bazelrc:
  Inherited 'always' options: --noenable_bzlmod
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=164
INFO: Reading rc options for 'build' from /Users/pcloudy/.bazelrc:
  'build' options: --verbose_failures --announce_rc --disk_cache=/tmp/bazel_disk_cache --repository_cache=/tmp/bazel_repository_cache
INFO: Analyzed target //:bin (40 packages loaded, 179 targets configured).
INFO: Found 1 target...
Target //:bin up-to-date:
  bazel-bin/bin
INFO: Elapsed time: 4.763s, Critical Path: 0.05s
INFO: 7 processes: 2 disk cache hit, 5 internal.
INFO: Build completed successfully, 7 total actions
pcloudy@pcloudy-macbookpro3:~/workspace/my_tests/empty_workspace (master), (bazel 7.0.2)
$ ls
BUILD                 WORKSPACE             bazel-bin             bazel-empty_workspace bazel-out             bazel-testlogs        main.cc

Note that we are also turning WORKSPACE off in Bazel 8, and plan to remove WORKSPACE in Bazel 9. See #23023

[jacobmou]

@meteorcloudy thank you for taking a look!
Yeah, i didnt find a way to reproduce it consistently, but many developers report it would show up after some build from time to time.
We also have always --lockfile_mode=off in our repo root .bazelrc file and with this, seems like we only see MODULE.bazel get produced. The file just has some comment about bzl_mod

###############################################################################
# Bazel now uses Bzlmod by default to manage external dependencies.
# Please consider migrating your external dependencies from WORKSPACE to MODULE.bazel.
#
# For more details, please check https://github.com/bazelbuild/bazel/issues/18958
###############################################################################

Thanks for the head up about dumping WORKSPAKCE. We will put it in our plan.

[meteorcloudy]

@Wyverald Is there any possibility that the ModuleFileFunction.java gets triggered when --enable_bzlmod is off?

[Wyverald]

Not that I know of. I just checked the code paths again, and it does look like we only ever eval ModuleFileValue.key() in code paths guarded by the --enable_bzlmod check.

[meteorcloudy]

@jacobmou Is it possible in some cases the bazelrc wasn't applied, for example, by passing --nohome_rc as something?

[jacobmou]

@jacobmou Is it possible in some cases the bazelrc wasn't applied, for example, by passing --nohome_rc as something?

We were suspecting the same thing. the always --noenable_bzlmod was specified in our repo root .bazelrc, and we dont have --noworkspace_rc in our repo. so the --noenable_bzlmod should always be applied.

so far seems like it's not causing any issue to our builds. I will try find a way to reproduce it, but if we can prove that's benign, we can just add it to .gitignore until we enable bzlmod. I will update here if we have new findings. Thanks for looking into this!