Bazelify and move to modules

[hsyed]

Happy to contribute this.

[rodaine]

Would love to see Bazel support added! But since dep has been superceded by go modules (né vgo), I'd say hold off on that side of things.

[hsyed]

Aah interesting I thought go modules was just for metadata !

I think the external dep approach (external deps declared as go_repository in the WORKSPACE file) is most appropriate for this project. WDYT ?

[rodaine]

My bazel-fu is pretty weak, but I'd say that makes sense to me. We are vendoring PG* in lyft/protoc-gen-validate , which uses bazel, but a custom version of the go ruleset, so not sure how this will interplay.

@htuch, any suggestions on this front?

[htuch]

My Bazel Go fu is the weakest of them all. Once protoc-gen-star is Bazel, we can consume it as an external Bazel native dep (go_repository) in PGV, so that would be great. In terms of how to make it happen, maybe check out https://github.com/bazelbuild/bazel-gazelle and generate the BUILD files automagically, this is what we did for PGV.

[hsyed]

I have had a look at vgo. Gazelle uses the lock file generated by dep to manage the workspace. vgo doesn’t use lock files. Using dep makes sense here, the validation framework uses it. It will likely take some time till solid support is availble in the rules.

The validation framework can be moved to the external workspace pattern and if we use dep here managin deps and regenerating the workspaces will be a cinch. Also the vendor directory can be excluded from vcs.

[rodaine]

Given that dep has been superseded by modules, we'll want to go that route instead.

[rodaine]

Closed by #81