bazelbuild/bazel

Using `--registry=file://%workspace%` instead of `--registry=file:///%workspace%` works on Linux but fails on Windows with a cryptic message

Open

#21,968 opened on Apr 11, 2024

View on GitHub
 (0 comments) (0 reactions) (2 assignees)Java (4,465 forks)batch import
P2area-Windowshelp wantedteam-ExternalDepstype: bug

Repository metrics

Stars
 (25,384 stars)
PR merge metrics
 (Avg merge 22d 20h) (77 merged PRs in 30d)

Description

Description of the bug:

When using a local bzlmod registry (using the pretty much undocumented %workspace% place holder to use a registry relative to the workspace), I first was using --registry=file://%workspace%/some/path which was happily working on Linux, but failing on Windows with

ERROR: Error computing the main repository mapping: in module dependency chain <root> -> googletest@1.14.0.bcr.1: Error accessing registry file://%workspace%/some/path: C

which is not super helpful. Switching to --registry=file:///%workspace%/some/path with a triple / has solved the issue, but it wasn't immediate to understand that.

Which category does this issue belong to?

No response

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

Create a local bazel registry relative to the workspace, and reference it with --registry=file://%workspace% instead of --registry=///%workspace%, add at least one bazel_dep (doesn't have to be into the local registry, which AFAIK might also be empty), then run on Windows.

Which operating system are you running Bazel on?

Windows

What is the output of bazel info release?

release 7.1.1

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 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?

I'm supposing that %workspace% is being expanded to C:/... (or C:\...), which makes file://C:/... fail just saying C because it's an unexpected character? It would probably help having a bit more context to that error. Another possibility is do some explicit checking of %workspace% usage in --registry values, so that only stuff starting with file:///%workspace% is accepted, at least on Windows, and rejected with a helpful error otherwise. Finally, it would also help if %workspace% was actually mentioned somewhere in the documentation about --registry, maybe with an example usage.

Contributor guide