> Bazel does ignore those comments. Gazelle does not.
I really don't understand what you're saying.
gazelle does not seem to do anything related to the c dependencies there. The full diff gazelle generated is just changing "deps" in 'BUILD.bazel' files to include the library, and adding a "go_repository" to "deps.bzl". Not that it would matter anyway, gazelle is part of bazel.
There's no references to c dependencies anywhere in what gazelle produced. I could have hand-written those changes just as easily, without gazelle.
I'm only using gazelle here because that's the only go example that upstream has in the repo.
The "bazel build" part is very clearly the part that is looking for these C files, and doing so in a non-hermetic way.
It's possible to make it hermetic, sure, if you pay attention and vendor things or such, but it's obviously not required.
That's all I was saying, just like you can have python break hermeticity and depend on external C libraries, you can have go break hermeticity and depend on external c libraries. It's possible to use bazel such that it's hermetic, but it doesn't stop you from doing it wrong.
That's all this thread is about, is whether it's also possible to make these non-hermetic references in languages other than python.
Like, if you go back and read my commend and your comment a few up, you'll see that my original claim was just that you could impurely reference the host "libjack-dev", which I have very clearly shown you can, and your claim was that it's literally impossible to do that, which it very obviously is possible.
> There's no references to c dependencies anywhere in what gazelle produced. I could have hand-written those changes just as easily, without gazelle.
I get that this scenario is confusing but this is incorrect. The problem is that you are running Gazelle to generate the build files for third-party dependencies, and not just the build files in your own workspace.
This file is generated by Gazelle. Gazelle is the tool you are running when you run this command:
bazel run //:gazelle-update-repos
When you run that command, it generates go_repository() rules, which are a part of Gazelle. There are three things at play here—there’s Bazel, rules_go, and Gazelle.
Bazel by itself doesn’t have any Go rules. You need to use rules_go for that. The rules_go rules completely ignore any of those comments you’re talking about—all libraries you link in are specified by things like cdeps and clinkopts.
Gazelle is what fills those in, and go_repository() is a part of Gazelle. You can see that in the imports:
# This is part of @bazel_gazelle, not @io_bazel_rules_go.
load("@bazel_gazelle//:deps.bzl", "go_repository")
There are a few practical suggestions I have for dealing with this:
- Nix. Run Bazel inside a Nix environment that contains your C dependencies. (You can have Bazel bring in C dependencies using Nix, too, if you can set aside multiple weeks to figure out how to do that. I wouldn’t.)
- Make your Bazel more hermetic. It’s not completely hermetic out of the box, but you can configure it to be more strict.
- For pure Go projects, consider disabling CGO with --@io_bazel_rules_go//go/config:pure.
- For third-party dependencies which use CGO dependencies, vendor those dependencies. You don’t need to vendor everything, just the dependencies that use CGO.
My own personal experience is that Bazel has a damn steep learning curve, which is why I don’t like engaging in Bazel apologetics. Bazel is reproducible when used/configured correctly, and it’s way easier to use/configure Bazel to do that than it is to configure other systems—but it’s still a pain in the ass.
And my own personal experience with the Go ecosystem is that CGO usage is uncommon enough that, most of the time, I can get work done with CGO turned off. YMMV.
Okay, yup, you're right, the C dependency stuff is gazelle.
I'll still claim the meat of what I said was correct:
> If bazel allows impurely using that dependency from the host, like bazel allows for python, then you'll be able to run into similar issues.
> Admittedly, you'll usually get compilation errors for undefined references in compiled languages (modulo dlopen)
That's the important bit of my comment, and it indeed seems true that bazel, as commonly used for go with gazelle, does allow and even facilitate those impure references to host dependencies, so even though I didn't understand the details of it fully, my overall point seems entirely accurate.
I appreciate you taking the time to explain things in more detail and share some advice/wisdom on dealing with this!
I really don't understand what you're saying.
gazelle does not seem to do anything related to the c dependencies there. The full diff gazelle generated is just changing "deps" in 'BUILD.bazel' files to include the library, and adding a "go_repository" to "deps.bzl". Not that it would matter anyway, gazelle is part of bazel.
There's no references to c dependencies anywhere in what gazelle produced. I could have hand-written those changes just as easily, without gazelle.
I'm only using gazelle here because that's the only go example that upstream has in the repo.
The "bazel build" part is very clearly the part that is looking for these C files, and doing so in a non-hermetic way.
It's possible to make it hermetic, sure, if you pay attention and vendor things or such, but it's obviously not required.
That's all I was saying, just like you can have python break hermeticity and depend on external C libraries, you can have go break hermeticity and depend on external c libraries. It's possible to use bazel such that it's hermetic, but it doesn't stop you from doing it wrong.
That's all this thread is about, is whether it's also possible to make these non-hermetic references in languages other than python.
Like, if you go back and read my commend and your comment a few up, you'll see that my original claim was just that you could impurely reference the host "libjack-dev", which I have very clearly shown you can, and your claim was that it's literally impossible to do that, which it very obviously is possible.