MODULE.bazel.lock file contains user specific paths

[jsharpe]

Description of the bug:

If you use a workspace local registry then the attributes recorded in the lockfile contain the expanded value for %workspace% instead of using the %workspace% placeholder.

Which category does this issue belong to?

External Dependency

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

Use --registry=file://%workspace%/registry and then depend on a module in that registry.

The applied patches from the registry are referenced using the expanded path of %workspace% instead of using a placeholder.

Which operating system are you running Bazel on?

Ubuntu linux

What is the output of bazel info release?

6.4.0rc1

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

No response

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

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

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

[jsharpe]

@bazel-io flag

[iancha1992]

@bazel-io fork 6.4.0

[iancha1992]

A fix for this issue has been included in Bazel 6.4.0 RC2. Please test out the release candidate and report any issues as soon as possible. Thanks!

[BoleynSu]

@iancha1992 @SalmaSamy The issue is still not fixed for extensions. See

bazel/src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleFileGlobals.java

Line 520 in 8e8ddab

private final Location location;

[meteorcloudy]

@BoleynSu Can you please give more details of what's still broken? Ideally with a minimal reproducible case.

[BoleynSu]

      "extensionUsages": [
        { 
          "extensionBzlFile": "@rules_java//java:extensions.bzl",
          "extensionName": "toolchains",
          "usingModule": "[email protected]",
          "location": {
            "file": "file://PATH_TO_LOCAL_REGISTRY/modules/rules_java/7.3.2/MODULE.bazel",         
            "line": 19,
            "column": 27
          },
          "imports": {
            "remote_java_tools": "remote_java_tools",
            "remote_java_tools_linux": "remote_java_tools_linux",
            "remote_java_tools_windows": "remote_java_tools_windows",
            "remote_java_tools_darwin_x86_64": "remote_java_tools_darwin_x86_64",

It should be repro-able by building any repo with --registry=file://some_local_checkout_of_bcr.

[Wyverald]

This is working as intended. If you're using a local path registry, we have to write the path to the lockfile to ensure reproducibility (unless the path is under the workspace root). If you're just doing some local testing and don't want to commit things into the lockfile, please use --lockfile_mode=off.

[BoleynSu]

Sorry that I did not make it claer. The local path is within workspace, i.e. %workspace%/reg.

[Wyverald]

@SalmaSamy could you try to repro and investigate? And close if unreproducible.

[appthumb]

Also, I'm using bazel 7.1.1.

$ bazelisk --version
bazel 7.1.1

[meteorcloudy]

@SalmaSamy Can you take a look?

This seems to happen when source.json is using local_path

{
  "type": "local_path",
  "path": "repo_A"
}

[fmeum]

@SalmaSamy I just noticed that this would go away entirely with the new lockfile format as neither local registry contents nor any repo specs for Bazel modules are tracked in it.

[iancha1992]

A fix for this issue has been included in Bazel 7.2.0 RC1. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=7.2.0rc1. Thanks!

[appthumb]

Thanks for the fix! It works smoothly with my local bazel registry, and the MODULE.bazel.lock doesn't include any local path and works fine across different workspaces. Interestingly, when I look at the lock file, the dependency on my local repo is not mentioned at all, which seems to be intended according to #19621 (comment).

Overall this is very nice, thanks!