All of my clients use Bazel now, so I've started using Bazel. I like it a lot, but there are some kludges when you get into any non-trivial chain of dependencies.<p>First off, if you depend upon another Bazel project which has its own dependencies, you need to clone dependencies from its WORKSPACE into yours for any targets you are hitting. If they chose to include macros for importing their dependencies, you may use those, but this would be opt-in. This is not technically unreasonable; you have all the power you need to have everything in your project depend upon a single version of a shared library or potentially import multiple versions (depending on how tangled the tree is), but you have to use this power, even if you don't care. Compare this to a non-sandboxed, more naive build using whatever version of libraries was found in the environment. You have the means to tightly control what is in the environment, or not care. With Bazel you have to care.<p>The dependency chain has led to a problem in practice when I tried to use Google's protobufs and Cython at the same time. The protobuf generated Python bindings use a particular version of Cython and override Cython's own Bazel rules, which seemed like a very rude and unnecessary practice. This made it impossible for me to use Cython in the same project as protobufs. A bug report to protobuf was met with "PR welcome."<p>As far as I can tell there are no "best practices" or features in Bazel to ease this kind of degenerate dependency chaining. If there are, a popular Google library decided not to use them. I consider dependencies to be the best and worst thing about Bazel; when it works it just works, when it doesn't it really doesn't.<p>All that said, I would probably use Bazel over pretty much any other alternative for business software in C++. For one-offs and PoC it is overkill.