Reproducibility in Disguise: Bazel, Dependencies, and the Versioning Lie

submited by

Style Pass

2024-07-03 04:30:03

Reproducibility has become a big deal. Whether it’s having higher confidence in one’s build or trying to better understand your supply chain for provenance, having an accurate view of your build graph is a must.

Tools such as Bazel have picked up mainstream usage from their advocacy by large companies that use it or via similar derivatives such as Buck. These companies write & proclaim how internally it’s solved many of their software development lifecycle problems. They’ve graciously open-sourced these tools for us to use so that we may also reap similar benefits. Sounds great right?

These companies however have a very distinctive software development practice from most of us: they vendor all their dependencies.

Vendoring all third party dependencies has proven too onerous for most. Few developers truly understand the amount of code they pull in via transitive dependencies from their language package managers.

To help those onboard to Bazel, the tool has introduced incrementally the concept of non-vendored dependencies (remote repositories) and integration with typical language package management tools such as maven, pip or npm. More recently, they’ve fully launched the bazel mod system which is a semantic versioning solver for dependencies. These are features that are not used internally at these companies that promote and have built out the tools themselves.