[aschleck]

Bazel works well when you're in Google's situation: many teams working on separate but connected projects, in multiple languages, infinite money to fund infrastructure teams and near constant migrations, a mandate that all code (*approximately) must be developed using it, and a culture of vendoring every dependency. Meanwhile the typical OSS project is a group of folks working on a monolith in one or two languages, and the predominant development culture avoids vendoring (for better and worse.)

I'm a strong apologist for Bazel, but I can absolutely see why projects avoid it. The more you deviate from what Google does the more paper cuts you'll get, but the less work you'll have to do. Bazel is great but it's certainly not a clear win in the general case.

[amardeep]

I also think it is partly as the tooling is not there yet - especially in the typical case when a project depends on lots of external dependencies.

I am looking forward to new set of bazel rules being worked on for eg. https://github.com/aspect-build/rules_js and https://github.com/jvolkman/rules_pycross which will makes it more idiomatic to work with existing language ecosystems.

[SilverBirch]

I think you've hit the nail on the head with the comment about funding infrastructure teams, where I work there's a mandate to use Bazel everywhere, but the project I'm working on basically doesn't use it because our use case doesn't fit nicely with the existing bazel infrastructure (it's currently not hermetic). The infra team who say we should all be using bazel also say that we can't use the the CI infra they maintain unless we're bazel. So we're basically out in the cold, but despite insisting we must do it their way, they don't offer to support our use case.