Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nobzlmod behaves very differently than bzlmod #2672

Open
mvukov opened this issue Jun 1, 2024 · 4 comments
Open

nobzlmod behaves very differently than bzlmod #2672

mvukov opened this issue Jun 1, 2024 · 4 comments

Comments

@mvukov
Copy link
Contributor

mvukov commented Jun 1, 2024

Related to #2650 , now I made small minimum example in a separate repo: https://github.com/mvukov/rules_rust_bzlmod_vs_nobzlmod.

bzlmod works as expected:

cd rules_rust_bzlmod
bazel run //:rust_main
# add a comment in BUILD.bazel (just edit it)
bazel run //:rust_main # nothing happens as expected

nobzlmod behaves funky:

cd rules_rust_nobzlmod
REPIN=1 bazel run //:rust_main
# add a comment in BUILD.bazel (just edit it)
bazel run //:rust_main

and now the drama starts, the first thing I see is:

Another command (pid=3841104) is running. Waiting for it to complete on the server (server_pid=3804232)...

and after a couple of seconds:

Computing main repo mapping: 
    Fetching repository @@crates; starting
    Fetching repository @@rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools; starting

... where this step also takes some seconds to complete.

My machine runs on Ubuntu 22.04, Bazel version is 7.1.2.

I'd like to help, but honestly I don't know where to start.

@matts1
Copy link
Contributor

matts1 commented Jun 4, 2024

@Wyverald might know more.

You might want to try USE_BAZEL_VERSION=6.5.0 (with bazelisk). Bazel 7.0 flipped bzlmod on by default, so it could be related to that.

@illicitonion
Copy link
Collaborator

I don't reproduce this. My guess from the "Another command is running" part is that you have rust analyzer or something running in the repo, and that it's running a bazel command with a different configuration (e.g. different env vars set) which is thrashing your in-memory caches?

@otiv-milan
Copy link

I thought about that. The steps I listed above are from a single terminal session, no e.g. vscode terminal. FWIW, my installation doesn't have rust-analyzer. Digging deeper...

@mvukov
Copy link
Contributor Author

mvukov commented Jun 16, 2024

OK, this issue seems to be related to vscode Bazel extension. I just removed it and I don't observe the behavior above. It's not a big issue for me as I used the extension only for syntax highlighting anyway. On the other hand, this is very strange, as this behavior only happens with rules_rust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants