Update to Bazel 7.2.1

We now use the lock file for local optimization, but do not check it in
yet. We will try out this feature a bit before doing so.

Bazel 7.2.1 also offers performance improvements, see:
bazelbuild/rules_python#1653 (comment)

.bazelrc

@@ -1,14 +1,6 @@
 # Always tell why tests fail
 test --test_output=errors
 
-# The performance gains offered by the lockfile are minimal for us.
-# Pinning the dependencies should be superfluous from a reproducibility perspective as the central registry is supposed
-# to be immutable for a module X in version Y after it has ben registered with the registry (ignoring the possibility of
-# yanking a module). Furthermore, the module resolution is deterministic.
-# However, there are several open issues suggesting the lock file will change in one way or another.
-# Thus, we don't use the bzlmod locking yet.
-common --lockfile_mode=off
-
 # When working with hermetic Python toolchains, supporting the legacy runfiles layout is needlessly wasting resources.
 # See https://github.com/bazelbuild/rules_python/issues/1653
 common --nolegacy_external_runfiles

.bazelversion

@@ -1 +1 @@
-7.1.1
+7.2.1

.gitignore

@@ -2,6 +2,7 @@
 
 # Bazel
 bazel-*
+*MODULE.bazel.lock
 user.bazelrc
 
 # Python

examples/.bazelrc

@@ -8,11 +8,3 @@ common --nolegacy_external_runfiles
 
 # The symlinks are annoying
 common --experimental_convenience_symlinks=clean
-
-# The performance gains offered by the lockfile are minimal for us.
-# Pinning the dependencies should be superfluous from a reproducibility perspective as the central registry is supposed
-# to be immutable for a module X in version Y after it has ben registered with the registry (ignoring the possibility of
-# yanking a module). Furthermore, the module resolution is deterministic.
-# However, there are several open issues suggesting the lock file will change in one way or another.
-# Thus, we don't use the bzlmod locking yet.
-common --lockfile_mode=off

examples/.bazelversion

@@ -1 +1 @@
-7.0.0
+7.2.1

test/apply_fixes/execution_logic.py

@@ -42,10 +42,11 @@
 # Decrease Python toolchain overhead
 # See https://github.com/bazelbuild/rules_python/issues/1653
 common --nolegacy_external_runfiles
+# Useless as the workspace are thrown away after each creation
 common --lockfile_mode=off
 """
 
-BAZEL_VERSION = "7.0.0"
+BAZEL_VERSION = "7.2.1"
 
 
 def dwyu_path_as_string(dwyu_path: Path) -> str:

test/aspect/.bazelrc

@@ -4,11 +4,3 @@ common --nolegacy_external_runfiles
 
 # The symlinks are annoying
 common --experimental_convenience_symlinks=clean
-
-# The performance gains offered by the lockfile are minimal for us.
-# Pinning the dependencies should be superfluous from a reproducibility perspective as the central registry is supposed
-# to be immutable for a module X in version Y after it has ben registered with the registry (ignoring the possibility of
-# yanking a module). Furthermore, the module resolution is deterministic.
-# However, there are several open issues suggesting the lock file will change in one way or another.
-# Thus, we don't use the bzlmod locking yet.
-common --lockfile_mode=off

test/aspect/execute_tests.py

@@ -25,11 +25,6 @@
     # We support Bazel's modern dependency management system, but it works only as desired with a recent Bazel version
     "--experimental_enable_bzlmod=false": CompatibleVersions(before="6.0.0"),
     "--enable_bzlmod=false": CompatibleVersions(minimum="6.0.0", before="6.2.0"),
-    # We are not yet sure if we really want to lock the bzlmod resolution down given we test with various Bazel versions
-    # and configurations. It seems the main benefits of the lock file are not having to reanalyze the central registry
-    # when working without a cached workspace and being safeguarded against changed or yanked modules in the central
-    # registry. Both don't matter much to us right now.
-    "--lockfile_mode=off": CompatibleVersions(minimum="6.2.0"),
     # Incompatible changes
     "--incompatible_legacy_local_fallback=false": CompatibleVersions(minimum="5.0.0"),  # false is the forward path
     "--incompatible_enforce_config_setting_visibility": CompatibleVersions(minimum="5.0.0"),