Proposal: Add bazel workspace, and build definitions to delve

[cessien]

This is just a feature proposal: Using bazel/gazelle to build delve, so that downstream bazel projects can easily do things like hermetically build and inject delve into remote debug containers.

example: in my repo I could add a line like this:

container_layer(
  name = "debug",
  directory = "/debug",
  files = [
    "@com_github_go_delve_delve//cmd/dlv:dlv",
  ]
)

if there were bazel/gazelle maintained dependencies, like in my fork

This would require running gazelle to keep new dependencies added to .go, go.mod files in sync with bazel (autogenerated) files:

bazel run //:gazelle -- update
bazel run //:gazelle -- update-repos --from_file=go.mod

Please answer the following before submitting your issue:

1. What version of Delve are you using (dlv version)?

Delve Debugger
│Version: 1.3.2
│Build: $Id: 569ccbd514fc47c8b4c521b142556867ec5e6917 $

2. What version of Go are you using? (go version)? go version go1.13.1 darwin/amd64.

3. What operating system and processor architecture are you using? macOS Mojave, 2.9 GHz Intel Core i7

4. What did you do? I am trying to use bazel to build delve upstream, as a remote headless debugger.

5. What did you expect to see? I would love it if the BUILD and WORKSPACE files for compiling dlv using bazel. Bazel has the ability to manage upstream source code, but it would be a one-liner for other repos downstream if there were bazel project definitions defined in this project.

6. What did you see instead? I manage bazel-defined Upstream dependencies in our repo, so that we can build delve with bazel.

[aarzilli]

Is there really no way of doing this without a file in every directory?

[cessien]

I could look into it, but these bazel build files are autogenerated by a popular tool gazelle for every re-usable package of code you have. With tuning, the vendor directories can all be managed via one build file which might greatly reduce the files generated.

Actually come to think of it, I can probably reduce the definitions down to a handful of files (ditch gazelle). I'm sure others using bazel would me most interested only in the actual cmd/dlv target

[dcartertwo]

+1 would love to see this feature

[michaelDovgal]

This can be very useful. or as alternative providing a fixed binary for dlv can be useful as there is bazel rule to pull external files

[benjaminws]

Any chance someone could revisit this? Would be incredibly useful.

[habib-farr]

+1

[derekparker]

I’ll be honest, I’ve heard mostly horror stories of folks using bazel. Most of the benefit, I’d imagine, would come from using it to build very large complex projects. While I consider delve a large and rather complex project, it is not complex to build.

Kubernetes recently removed bazel to simplify its own build system and I would consider that a complex project to build. https://github.com/kubernetes/kubernetes/pull/99561

What other existing projects are still using bazel and would benefit from this, and specifically how do they benefit from it? Lastly, what’s the benefit for this project? Why introduce a complex build system? Is it just for the benefit of other projects using this complex build system?

[stabai]

Why introduce a complex build system? Is it just for the benefit of other projects using this complex build system?

Yes. Anyone who uses Bazel to build their Go code will have an awkward experience trying to debug it with Delve. Ideally, what we need is just some Bazel rules that orchestrate Delve into the Bazel system. This is typically in a separate repository from the tool itself (e.g. rules_go has the Bazel rules for Go, but not the Go SDK itself).

To add context, I might run my Go tests with Bazel using:

bazel test my/app:tests

The easiest solution would be if I could add a --go_debug flag to the end of that command to tell it that it should run using Delve instead of the standard runner. I'm pretty sure this would just require changes in the existing go_test rule though: https://github.com/bazelbuild/rules_go/blob/master/go/private/rules/test.bzl

The alternative is to create a new Bazel rule for using Delve. I don't think that would be an ideal option though, as it seems like it makes more sense to add this to the rules_go standard repository if they're open to it.

I've filed https://github.com/bazelbuild/rules_go/issues/3277 for that in the rules_go repo.

[derekparker]

@stabai thanks for your insight, I appreciate it. I think the approach you've gone down with the go_test rule seems to be the best path forward. Do you still think there would be any benefit over hosting any bazel specific rules within a separate repo under the go-delve org?

If the rules are allowed to live in another repo I'm more open to it. I just really don't want to include a bunch of bazel related files in this repo when we won't be using them at all.

[stabai]

Personally, I think the rules_go repo is the right place for this. However, at the end of the day, it's up to the Bazel folks that own that repo. I'm somewhat new to Go, but it seems to me like Delve has enough mindshare to warrant adoption into their standard rules. The only reason I'd suggest putting it under the go-delve org instead is if you want to have more control over the functionality and release process for the Bazel plugin.

If for some reason they're unwilling to include Delve in rules_go, then yes, creating a new repo under the go-delve org makes sense. I'd definitely suggest that rather than adding Bazel instrumentation into this repo. There's also a pretty good template repo to use as a starter for that: https://github.com/bazel-contrib/rules-template