Module handling

[dvtkrlbs]

We need to have a way to handle go modules. They consist of multiple libraries (in buck sense) and kind of a pain to handle directly. I wrote some hacky go code to first parse the output of go mod graph and then download all the dependencies and also parse every go file in the module.zip file to handle dependencies of every subfolder (it doesn't work fully but I need to clean the code first). Bazel gazelle handles this by having a go-repository rule that handles this on the starlark side from what I see. We need to decide on in which side we want to handle this. I am leaning towards buck2-go side since third party repo handling is not as good as bazel since there is no repository phase.

Geomys

[sluongng]

I think the correct approach is somewhere in between of Bazel Gazelle today (not update-repos approach, but the bzlmod approach), and https://github.com/facebookincubator/reindeer

You could look into these small tasks:

• Parse go.mod and generate http_archive subtargets
• Modify Gazelle to generate BUCK files (instead of Bazel BUILD files) with buck2-go / buck2 prelude rules
• Decide when to run gazelle for external repo
  • In a separate process like gazelle/reindeer
  • In buck2 build graph (not sure if this is possible)

Because buck2 does not have a repository rule phase, most likely you would have to check-in the generated BUCK targets into a third-party/go repository for each module.