Bazel: Every .bzl file must have a corresponding package, but '@rules_cc//cc:defs.bzl' does not have one

[GMNGeoffrey]

Description of the problem / feature request:

Twice in the last two days when returning to rebuild a Bazel project, I've seen an error about it being unable to find the .bzl file for rules_cc rules. I think this has to do with the implicit loading of rules_cc by Bazel, as you'll notice that nowhere is that file mentioned in the repository (https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/google/llvm-bazel%24+%22cc:defs.bzl%22&patternType=regexp).

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

As this is a non-deterministic thing, it's a bit hard to reproduce. It seems to happen basically every time I fetch new commits in https://github.com/google/iree or https://github.com/google/llvm-bazel

What operating system are you running Bazel on?

Linux Debian

What's the output of bazel info release?

Happens with Bazel 3.3.1 and 3.7.1

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

$ git remote get-url origin ; git rev-parse main ; git rev-parse HEAD
[email protected]:GMNGeoffrey/llvm-bazel.git
e463a75a963dc583ef1ccc6122aceaaabd5b8e09
e463a75a963dc583ef1ccc6122aceaaabd5b8e09

Have you found anything relevant by searching the web?

No

[GMNGeoffrey]

This happens to me just about every time I fetch new stuff from the repository at this point.

[GMNGeoffrey]

Oops it looks like I didn't finish filling out the issue report. I am now running bazel clean --expunge multiple times a day for different repositories because of this issue

[vnvo2409]

@GMNGeoffrey I got this issue recently. I found there are 2 ways for fixing it.

• Just load it by using load("@rules_cc//cc:defs.bzl", "cc_library") without adding rules_cc to your WORKSPACE ( I think it is the rules_cc that is packed by default with Bazel.
• If you add rules_cc in your WORKSPACE, you have to add a strip_prefix, that works for me ( With this rules_cc, you can use more advanced features like cc_shared_library ).

http_archive(
    name = "rules_cc",
    strip_prefix = "",
    urls = ["https://github.com/bazelbuild/rules_cc/archive/TODO"],
    sha256 = "TODO",
)

[GMNGeoffrey]

Thanks. That then brings us to https://github.com/bazelbuild/buildtools/issues/923 :grin: I also find I get this with rules_python

[GMNGeoffrey]

Now also getting this with @bazel_sklyib//:workspace.bzl

ERROR: error loading package '': Every .bzl file must have a corresponding package, but '@bazel_skylib//:workspace.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist.

We use this in our WORKSPACE file and do load it normally, I think, so maybe this isn't just a rules_cc thing?

https://github.com/google/llvm-bazel/blob/4c8b546e53eebc708c77ba19a2110926a8732642/llvm-bazel/WORKSPACE#L60-L69

[vnvo2409]

@GMNGeoffrey

Just add the strip_prefix will solve your problem.

And I think it is how bazel works indeed. If you don't add strip_prefix, bazel will download the http_archive https://github.com/bazelbuild/bazel-skylib/releases/download/1.0.2/bazel-skylib-1.0.2.tar.gz to a folder named bazel-skylib-1.0.2. When you want to load something from that folder, you might have to do something like @bazel-skylib//bazel-skylib-1.0.2/....

What do you think ?

[GMNGeoffrey]

Hmmm what you describe has been my experience with other http_archive usage from GitHub releases. I believe I copied this from the instructions at https://github.com/bazelbuild/bazel-skylib/releases/tag/1.0.2 though and it looks identical. Also the error I experience here is non-deterministic, which isn't the kind of error I'd expect here.

And testing it out, the Bazel skylib release archive does have different behavior here. I believe it does something fancy to avoid the need for the strip_prefix

gcmn@lt 2021-01-07 16:56 ~/Downloads/bazel-extract-test$ mv ../bazel-toolchains-3.3.1.tar.gz ./

gcmn@lt 2021-01-07 16:56 ~/Downloads/bazel-extract-test$ tar -xzf bazel-toolchains-3.3.1.tar.gz 

gcmn@lt 2021-01-07 16:56 ~/Downloads/bazel-extract-test$ ls
bazel-toolchains-3.3.1  bazel-toolchains-3.3.1.tar.gz

gcmn@lt 2021-01-07 16:56 ~/Downloads/bazel-extract-test$ rm -rf *

gcmn@lt 2021-01-07 16:57 ~/Downloads/bazel-extract-test$ mv ../bazel-skylib-1.0.2.tar.gz 
mv: missing destination file operand after '../bazel-skylib-1.0.2.tar.gz'
Try 'mv --help' for more information.

gcmn@lt 2021-01-07 16:57 ~/Downloads/bazel-extract-test$ mv ../bazel-skylib-1.0.2.tar.gz ./

gcmn@lt 2021-01-07 16:57 ~/Downloads/bazel-extract-test$ tar -xzf bazel-skylib-1.0.2.tar.gz 

gcmn@lt 2021-01-07 16:57 ~/Downloads/bazel-extract-test$ ls
bazel-skylib-1.0.2.tar.gz  bzl_library.bzl  CONTRIBUTORS       internal_setup.bzl  lib.bzl  rules                toolchains   workspace.bzl
BUILD                      CODEOWNERS       internal_deps.bzl  lib                 LICENSE  skylark_library.bzl  version.bzl

So note that the archive structure for bazel_skylib doesn't have the nesting