FR: Why Bazel?

[prestonvanloon]

Feature request: add documentation page with a full, in-depth, rationale around the design choice around bazel build tooling and why it is critical to the success of Prysm.

[prestonvanloon]

Note: Please update DEPENDENCIES.md with the proper link for Why Bazel? after it has been created. See prysmaticlabs/prysm@6629ec4

[rkapka]

This would be great. As a contributor to the project I would also like to understand how exactly Bazel and Go co-exist in the project. Here is my question that I asked on Discord;

and by the way, what does it mean exactly that bazel is no longer needed? won't it still be necessary to update the BUILD files etc?
I mean, if someone wants to use only go tools and another person wants to use bazel, won't the first person's bazel-ignorant PR break the bazel build?

[maulerjan]

Any updates?

[smijolovic]

Can the documentation include the "how" on building without Bazel? While I have read through the rationale, there are plenty of reasons and examples of how dependency managers like bazel exponentially increase the number of vulnerabilities in produced products (legacy compilers and baseimages locked into bazel releases or Workspace workflows). We are very much against the use of these dependency managers as they are leading to vulnerability explosions in software today.

Is there a detailed document/process for a release build of the c++ lib dependencies, rpc gRPCs libs, compile optimization flags, go build process for beacon-chain and validator, and dockerfiles for creating the containers?

The lack of the build process and dependency abstraction is of great concern.

[rauljordan]

Hi @smijolovic we agree with some of the concerns above. However, curious if you can give us evidence of bazel exponentially increase the number of vulnerabilities in produced products, particularly when bazel pins dependencies as defined in a WORKSPACE file. We will work on answering some of these concerns in our documentation portal soon