[habitue]

Good heuristic for whether it's worth considering moving to bazel for your build system:

- Do you have 200+ developers working on a monorepo?

- Are you willing to vendor all of your dependencies and maintain their builds yourself?

If so, consider it. The productivity you're losing to unnecessary rebuilding and re-running unchanged unit tests will probably be paid back if you can contort your development process to the one Bazel expects.

If you're a small shop, the benefits Bazel is going to provide over, say, Make (or whatever standard build system your primary language uses), are going to be minimal. And the overhead of maintaining Bazel is going to cost you a ton of developer time you may not be able to afford.

[wereHamster]

Another factor: are your languages supported by bazel? If you use the same languages that google uses (C++, Python, go), it's fair to say that those are well supported. For all other languages, even if they are widely used outside of Google (JavaScript, nodejs), you may be out of luck.

[zapita]

Go support is not great either. Bazel can build Go just fine, but you will need to throw away the standard Go tooling and use Bazel instead. There are third-party helpers like Gazelle, but you know you’re in for a bumpy ride when even basic operations require a helper.

[klodolph]

Go support is awesome, IMO. Personally I have favored Bazel over “go build” for a while, except for pure Go projects with no generated sources.

Gazelle is wonderful and it doesn’t belong in Bazel core. Bazel is a build system for every language, and Gazelle is for a subset of Go developers. Since it’s not part of Bazel core, you can always replace it with something else.

[zapita]

But would you recommend using Bazel and Go without Gazelle or an equivalent third party?

[klodolph]

I recommend Gazelle for importing third-party Go dependencies but not for your own Go code. If you are using Bazel, just write the BUILD.bazel file yourself with the appropriate go_library / go_binary / go_test rules.

[laurentlb]

Gazelle is a recommended tool, developed by the same people who make the Go rules. It's not a third party tool, it's part of the normal experience.

[thundergolfer]

Python is not well supported. The official rules_python has an inadequate third-party packaging solution that has led to ~5 open source alternatives existing that each fix a subset of the issues in the official.

Given that the Python community is really oriented around the PyPi registry and pip packaging tool having a good Bazel-native packaging solution is near essential, but right now it’s not quite there.

[lima]

Yeah, what's missing is first-party integration with the package manager (like Gazelle for Go) with proper dependency locking.

[jefftk]

I don't know much about bazel, but JavaScript is very widely used inside Google. It's the main language I work in.

[vlovich123]

So I always wonder how Google does this. Somehow they're able to determine which individual unit test are impacted by a change. Maybe this is only for Java but I'm pretty sure I recall claims that they can change 1 line & know that only 1 other test case is impacted (i.e. not even the other test cases within the same unit). Now Google's monorepo does imply also that if you are changing a line that is foundationally part of a lot of other components that they get rebuilt & retested too - that's the risk tolerance Google has chosen (i.e. they'd rather tests take longer if you're changing a core component rather than skipping tests & risking destabilizing 1000+ other engineers).

[habitue]

It depends on the granularity you write your BUILD files with. You can certainly write a target for each individual test, and track dependencies independently. In practice, you might glob together all files in a directory and put up with a few extra test runs in exchange for less bookkeeping

[vlovich123]

What I was saying is that Google somehow manages to track test dependencies at the source level so globbing wouldn't matter.

[joshuamorton]

Frankly you heard wrong. There isn't anything like this.

[vlovich123]

Yeah, I was misremembering the post from ~8 years ago. I was thinking of this https://testing.googleblog.com/2011/06/testing-at-speed-and-... and it sounds like they do just use Blaze to keep track of explicitly expressed dependencies.

[IshKebab]

I don't think you need 200 developers to make it worth considering.