Repo setup

[mattklein123]

Please use this issue to discuss general setup. I want to agree on a bunch of things before anyone starts pushing code:

• CI setup. (CircleCI)
• Build system. Bazel?
• Dependency tracking. Glide/godep/something else?
• Outline of project scope. What this is and what this isn't in README.

[mattklein123]

@kyessenov @junr03 @rshriram

@rodaine @twoism can you please advise/help with Go project setup.

cc @envoyproxy/maintainers

[kyessenov]

From Istio experience: we went with Bazel for go for build & dependency management, but it's rough, and everyone ends up using regular go tools anyways. However, it's fairly easy to convert Bazel workspace into a full-vendorized flat go build by symlinking stuff into vendor. I think we want Bazel for protobuf code generation, and we can either commit the generated code or not, based on the preferences.

[htuch]

Please setup with envoyproxy/data-plane-api#201 and native proto_library in mind.

[rshriram]

I suggest that we stick with Circle CI.. ITs pretty sleek.
Second, for build, I suggest we stick with standard go tooling, if we want this repo to be used by wide variety of projects. Keep in mind that not everyone builds Envoy from scratch. Forcing them to install bazel just to convert this into a go project is a non starter for adoption.

We also want to be able to take advantage of go standard tooling in CircleCI.. So, my suggestion would be to commit the pb.go files as most projects do. This entire on the fly generation merely saves a few key strokes of a simple make command, but adds a tremendous overhead.

[kyessenov]

Go tools are pretty nice, but dependency management is a zoo at the moment. go dep seems to be the future. Either way, I can maintain a Bazel build just to be able to import it elsewhere as Bazel infected lots of projects around Envoy already.

[rshriram]

Dependency tracking: Glide/godep is fine. Given that @junr03 is the one with existing implementation of a v2 library, I suggest we go with whatever he is already using (which happens to be glide).

We can have a Bazel build, but lets not make it as the canonical build system. We can have scripts that ensure that the bazel files are updated always, so that its easier to import in other bazel projects.

[9len]

Big +1 on standard Go tool chain, if you want broad adoption.

As long as we’re good about vendor hygiene (don’t leak vendored interfaces and types out of library code) I think any of the go dependency managers is fine.

I’m pro-circle too.

[cmluciano]

+1 for go dep

[rshriram]

So, is it settled then? Circle CI, standard go tool chain, glide? As for the scope, I can send a PR on the current scope (API server for data plane protos, and a cache layer. Not a translation layer, as @junr03 pointed out).

[mattklein123]

OK SGTM. My preference is no Bazel unless it's absolutely required which it sounds like it isn't. If we can only use Bazel in certain cases (like protobuf generation which gets committed) that sounds OK to me.

We are using glide at Lyft right now but I have no preference between go dep, glide, etc.

I will turn on CircleCI for this repo, so someone can then just do a PR to add a config.

@rshriram yes let's do a PR for scope in README, etc. Then we can get going.

[mattklein123]

CircleCI is enabled: https://circleci.com/gh/envoyproxy/go-control-plane/tree/master. You can commit v2 Circle configs when you are ready.

[rodaine]

Until dep is absorbed into the go toolchain, I'd prefer using glide. Later transitioning to dep should be straightforward as it relies on the same vendoring mechanics as glide.

[theatrus]

-1 Bazel
+1 dep (or glide), Glide authors are starting to suggest steering to dep on their latest release.

[mattklein123]

Project scope here: #2

Please review.

[skyrocknroll]

+1 go dep
-1 for bazel

[davecheney]

-1 for bazel as a hard requirement. As the other commenters have pointed out, if this project does not build with the standard Go tools, especially as #2 suggests it is a library that others will import and provide their own cache population mechanisms, then making bazel a hard requirement will significantly impact its utility.

As for dependency management. If you do this right, you shouldn't have any dependencies, and as long as you use a semver style tag when cutting releases, you'll be compatible with all the dependency management tools duking it out in the Go space at the moment.

[rshriram]

we can close this, as we now have CircleCI, glide, and standard go tools for building. Repo scope has been updated as well.