withered-magic / starpls

Getting "No such file or directory" if load statement in .bzl file uses current workspace. It works if simply //:file.bzl is used.

Looks like the logic here (current main) parses label as RepoKind::Apparent:

starpls/crates/starpls_bazel/src/label.rs

Line 192 in 8b11ada

fn parse_repo(&mut self) -> Result<RepoKind, ParseError> {

And later file is expected to reside in external repo, which it does not:

starpls/crates/starpls/src/document.rs

Line 279 in 8b11ada

RepoKind::Canonical | RepoKind::Apparent => {

I am using the full path for demonstration purposes - e.g. some projects may use a given file as an example and use in other repos where they need to use full path.

Ah I see, does your project currently have bzlmod disabled? This currently doesn't work for non-bzlmod projects because I couldn't find a good way to always correctly determine the current workspace name (i.e. respecting any workspace() calls in WORKSPACE.bazel), I'll try looking again to see if there's any better way to do so

Personally I can probably wait for bzlmod to be enabled in my project and will have a workaround till this time.

I have just checked that bazel-lsp extracts workspace (or main repository name) out of bazel info's execution_root:
https://github.com/cameron-martin/bazel-lsp/blob/92644f21aca7cfbba332c67ac1aa9cf43765e021/src/workspace.rs#L37

Hmm, I just tried that workaround locally (extracting the workspace name from execution_root), but I'm unable to get it to show anything but _main, so not sure that's a reliable enough source for the workspace name, e.g. I always get something like

/home/<redacted>/.cache/bazel/<redacted>/690003b795ac99fd4420988574586896/execroot/_main

even if I have a custom workspace name set with workspace().

Actually I guess this differs between Bazel versions, where for Bazel 7 it always defaults to _main and for Bazel 6 it honors the workspace name. I can add support for this workaround then!

Landed some preliminary support for this, although it only works for Bazel 6, let me know if this fits your use case!

It points to proper execroot in bazel 7 if you disable bzlmod (like bazel info execution_root --noenable_bzlmod).

Thanks, it works with the fix, tested on bazel 7.1.1 with bzlmod disabled.

"Could not resolve module" for load("@current_workspace//:file.bzl")