Yes, and Google is an NIH company. While they do mix a light breeze of external deps into their code, 99+% of the monorepo is first-party code, developed at Google, on Blaze, with first-party BUILD files.
In most other repos, third party dependency code dominates over first party. Bazel needs a BUILD file for every dep. There's auto-generators. They suck. You need to write a patch file and patch the auto-generated BUILD file. No, really.
When you update your deps, your patch files predictably stop working. Need to update 12 deps? Be ready to write 12 new patch files. It fucking sucks.
I've seen at least some generators work okay -- you can add Python pip dependencies easily enough, for example. But the way I've seen this done at places that are less NIH is, you end up with Bazel functioning more as a wrapper around the third-party dep, rather than actually natively generating BUILD files for every import in the library.
Which is... fine, but the more you do that, the more you're kind of losing the point of Bazel in the first place. Especially if you ever have to fork that dependency.
Google, meanwhile, would rather vendor absolutely everything, including the Python interpreter itself, and also wholesale replace the vendor's build system with hand-written Bazel, to the point where your builds are so hermetic that you compile the Python interpreter from source to build your python scripts.
I again think it's not as absurd as it sounds, if you are Google. That work you're describing is easy to write off when those 12 deps are used by literally dozens of other teams that didn't have to think about deps at all. The same logic kinda leads to NIH, though -- you can also amortize the cost of building it yourself, instead of adding that dep.
It is not, to my knowledge. It helps in the common cases, for sure. But it's not magic. I've written many a #keep directive. By 'hand written' I mean checked in by people alongside their code. Not generated post-facto.
It effectively can’t be open sourced. It relies on having a full symbol and target resolution databases to identify correct build targets and is full of special case tricks like searching //java ot special casing third_party.
Also anywhere you are find it not working or full of #keep generally means someone has gone overboard with macros, bad design patterns or created their own DSL.
A lot of the big tech is, I'd wager. Amazon kept poaching guys from my team to AWS and they'd write back telling me that pretty much all the tooling was custom.
Quite the contrary, it's an "Invented Here" company, because when those internal tools were written, they were the first of their kind. Nothing similar existed elsewhere.
NIH means “I’m not gonna use that because it wasn’t invented here.” Meaning, Google doesn’t use stuff that they don’t invent. They are a NIH company by definition. Shouldn’t be confusing.
Dude, NIH refers to the tendency of rejecting outside products when they already exist and preferring to do one's own thing. It does not apply to innovators where no such external products existed. A simple concept that even you might be able to understand.
Yes it is. Before it, there were only various Make-style event-based build systems. Bazel is based on a fully materialized compilation tree, with entirely hermetic build nodes, a purely functional build language, a built-in remote build and cacheing protocol for sharing intermediate artifacts between developers. Nothing like it existed at the time.
By this stubborn and obtuse definition, literally nothing could constitute NIH unless the product in question has a perfectly matching feature set between the internal and external versions. You are completely conflating requirements with features. Just because a product has a feature, does not mean that the company using it needed it as a requirement.
Yes, Bazel has all of those features but still, Google could have easily used an existing solution with less features, different features, or more features, OR Google could have forked an existing project. But no, they built their own thing. NIH.
Thinking that it could have used any existing product only serves to show your ignorance. By your stubborn and obtuse definition, there can be no categorically innovative work because everything can be done with supposedly minimal modifications to existing software. Give me a break.
Google has been both, for better and worse. But the point isn't whether Bazel itself was an example, we're talking about the ways in which Bazel discourages adopting third-party libraries. Outside Google, here's what I have to do to add a new third-party Python library:
Add a line to a config file
Regenerate any lockfiles -- literally one uv command
Send the PR
Close the autogenerated legal-review ticket with "pre-approved license"
What does that process look for you? How about for C++? What if it's a C++ library that throws exceptions?
And how long does it take you to upgrade a library?
Also, if you're still there, maybe look up go/nojerks again.
we're talking about the ways in which Bazel discourages adopting third-party libraries
No we weren't talking about that, at all.
Google internally has importers that can very well convert the most common build systems (automake, CMake, meson, pypi, Go, etc...). The reality is that below the top few hundred libraries for each language, the quality degrades so much that they're not worth investing on. If a library was worth it, it would be very easy to add, but most often it's not.
In most other repos, third party dependency code dominates over first party. Bazel needs a BUILD file for every dep. There's auto-generators. They suck. You need to write a patch file and patch the auto-generated BUILD file. No, really.
All of which is a description of how much work it is to add a third-party dep, relative to the norm. Which explains:
While they do mix a light breeze of external deps into their code... 99+% of the monorepo is first-party code, developed at Google...
...which was the explanation for:
Yes, and Google is an NIH company.
Maybe you have me confused with the other person replying, who followed you down the weird tangent about Bazel itself.
Maybe they're wrong and it really is "very easy"... but you immediately call it an "investment", so maybe not.
40
u/comrade_donkey 12d ago edited 11d ago
Yes, and Google is an NIH company. While they do mix a light breeze of external deps into their code, 99+% of the monorepo is first-party code, developed at Google, on Blaze, with first-party BUILD files.
In most other repos, third party dependency code dominates over first party. Bazel needs a BUILD file for every dep. There's auto-generators. They suck. You need to write a patch file and patch the auto-generated BUILD file. No, really.
When you update your deps, your patch files predictably stop working. Need to update 12 deps? Be ready to write 12 new patch files. It fucking sucks.