MODULE.bazel.lock file contains user specific paths

[jsharpe]

Description of the bug:

The lock file includes user specific paths in the location part of the extension usage sections.
This is a side effect of the change made to improve error messages by @fmeum.

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?

No response

What is the output of bazel info release?

6.3.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.

Yes this is a regression due to #18612

Have you found anything relevant by searching the web?

No response

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

No response

[fmeum]

@Wyverald @SalmaSamy The absolute paths come from Location's file field. Do you think we need to keep Location information in the JSON? If it is only used in error messages and the lockfile has been generated, maybe we can just drop that information?

If we want to preserve it, we would probably need to make the path relative to its root. But this doesn't look that easy since the root can vary (workspace root, external repo root, ...).

[SalmaSamy]

In some cases the location is required in the error messages after reading the data from the lockfile. I am not sure if it's okay to drop it. @Wyverald what do you think?

[Wyverald]

We shouldn't just completely drop the location, since the lockfile might not contain an extension that 1) hasn't been evaluated yet and 2) throws on evaluation. In this case we will need the location to report the error.

I was thinking that we should maybe just store a label-y thing for locations in MODULE.bazel files of modules with non-registry overrides. So @@foo~override//:MODULE.bazel instead of $OUTPUT_BASE/external/foo~override/MODULE.bazel. (This is the only case where we store a file path for MODULE.bazel IIRC; for modules without non-registry overrides we store the registry URL.) Then we could augment the bazel mod show_repo command a bit to show where the repo is actually located, and maybe also think about some sort of helper command that just straight up converts a label to a local file path. WDYT?

[Wyverald]

@bazel-io fork 6.3.0

[fmeum]

I was thinking that we should maybe just store a label-y thing for locations in MODULE.bazel files of modules with non-registry overrides. So @@foo~override//:MODULE.bazel instead of $OUTPUT_BASE/external/foo~override/MODULE.bazel.

Sounds good! If we use Label#getDisplayForm, that label will be reasonably friendly in the likely case where a module with a non-registry override is a direct dependency of the root module.

Then we could augment the bazel mod show_repo command a bit to show where the repo is actually located, and maybe also think about some sort of helper command that just straight up converts a label to a local file path. WDYT?

bazel cquery --output=files comes somewhat close, but doesn't quite get there: It only outputs paths relative to the output base and can't directly refer to MODULE.bazel unless its an exported file. So yes, something like this would be needed, but not urgently.

[fmeum]

Having thought about this some more, I like canonical labels more than the display form as they are closer to the actual location on disk.

We should probably also handle the root module specially as it is the one where errors are most likely to originate from. I am working on a PR for this aspect here.

[Wyverald]

I have a change in flight to fix non-registry overrides.