Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel 2.0

blog.bazel.build

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Bazel 2.0

#71

Post by vlovich123 »

djsumdog wrote: post #63

I hadn't heard of this, and see there is a lot of concern over using this project except for specific use cases. I'm always weary of build tools that try to do multiple languages. On Scala projects I use SBT, and for people who have tried to hack on SBT itself or its plugins, you know it's a big mess under there. On other projects I've tried using Gradle with Scala, but I found a lot of times Gradle just wasn't setup…

That works for small teams/projects. If you're looking at hundreds, thousand, or even tens of thousands person orgs you're spending time training everyone on every individual build system (very time-consuming and error-prone). Additionally because of the lack of consistency & unfamiliarity with having to deal with multiple interconnected projects, these tools fall apart spectacularly in that each team will end up with their own flavor of the build system. This makes transitioning between projects very hard & silos off teams.

That can be fine but can make it even more of an efficiency loss for someone switching projects/contributing partially to another project. Uniformity reduces costs on many fronts but like anything else it's a tradeoff. Now you need a team to maintain your Bazel/Buck/etc for each language & it may not jive 100% well with languages that have opinionated package managers/build systems alread (Node, Cargo, SBT, etc). On the other hand you'd probably end up having to create teams to maintain your company's Node, Cargo, SBT builds anyway except now you need to hire domain experts who not only understand each language but also how it should integrate within your larger infrastructure. A single uniform build system framework makes that easier.

Re: Bazel 2.0

#72

Post by vlovich123 »

habitue wrote: post #62

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 th…

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).

Re: Bazel 2.0

#73

Post by ivanbakel »

serverholic wrote: post #50
taeric wrote: post #46

Earlier quoted context omitted.

Oddly, this is also one of the bad sides. Committing to two projects, by necessity, means deploying to two workflows. If not more. Doing that in one repo makes the commit part easier, but hides the complexity of deploying separately. Or to other places. Not that two repos makes it easy. Just gives a much earlier signal to where it happens.

Or you can have a single workflow that includes all the projects in the repo. I found it's actually easier to do things like wait for project A to deploy before project B.

Only if the safe deployment order is always the same. In any typical server-client deployment, breaking changes can go in either direction, and which one you can deploy first requires some thought. I've seen 3- or 4-stage deployments for some back-and-forth changes.

In my experience, you're required to break changes up into safe individual deployments anyways, so the monorepo doesn't add any benefit in that sense.

Re: Bazel 2.0

#74

Post by ecnahc515 »

dehrmann wrote: post #45
serverholic wrote: post #40

Earlier quoted context omitted.

Well for one you can commit to multiple projects in a single PR. Makes coordinating changes across projects much easier.

It gives you that illusion; it doesn't solve versioning and deployment orders, and I'd argue that that's the harder part of changes across projects. Polyrepos make messy things...messy.

Deployment ordering at large scale is avoided and usually done by not making breaking changes. 4 phase migrations, always. Roll out new API, update existing software to use new API, wait for everything to stop using old API + backfill, remove old API.

Re: Bazel 2.0

#75

Post by derkha »

habitue wrote: post #64
zellyn wrote: post #56

Earlier quoted context omitted.

If I understand it correctly (unlikely), Nix has the degree of purely-functional rigor necessary to do this correctly, right? Sounds like it would eventually be awesome for Bazel usecases.

Nix isn't great as a build system, because it throws a lot out and rebuilds everything when something changes. It's intended to get a correct, isolated package installed, not to maximize sharing. Bazel goes through great pains to only rebuild the minimum necessary for correctness. It's able to do that because bazel build files get a lot more information about the source level dependencies than a Nix file does

Reading through https://bazel.build/designs/skyframe.html, this sounds pretty much like what would be possible with the aforementioned recursive Nix and content-addressed paths. Bazel might still win in practice since the overhead of a Nix build is pretty high, which gets even more important when you do them recursively for each file.

Re: Bazel 2.0

#76

Post by ajconway »

boris wrote: post #57
ajconway wrote: post #39

Earlier quoted context omitted.

> run as fast as you can in the opposite direction But which one? Are there any other (non blaze-like) build systems enabling hermetic (possibly remote) builds and caching? If you don't need these properties and have a mono language project, the language's native build system sure fits and may be a better choice.

There is build2. It has "high-fidelity" (instead of hermetic) builds meaning that besides sources it keeps track of changes to options, compilers, etc. This gives you similar benefits at a fraction of the cost. There is no distributed compilation or caching yet but it's coming. In other benefits, it doesn't need Java or Python (or any other "platform").

One of the main benefits of Bazel (and similar systems) is that you get a build cache that you can mostly trust. When you have a project that takes an hour or more to build and test, and lots of machines to run a distributed build, it really makes a difference.

If you have a small project that you can rebuild in a couple of minutes, Bazel is probably an overkill.

Re: Bazel 2.0

#77

Post by dub »

breatheoften wrote: post #67

Does bazel use the word “provenance“ at all? Provenance is a word I first saw advertised in a platform called dotscience.io — that I find fundamentally interesting. And it seems quite relevant to hermetic builds. Provenance is about giving any state derived from an arbitrary computation an identity that is derived from the content hash of the inputs needed to re-compute that state ... in dotscience they achieve this…

Bazel is part of the story of how Google manages provenance for build artifacts (https://cloud.google.com/security/binary-authorization-for-b...)

Re: Bazel 2.0

#78

Post by weberc2 »

zellyn wrote: post #15
ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

If you are an organization with a large enough codebase (especially if it's in a monorepo) that you need a shared remote cache of build artifacts, or remote build sharding and execution, and have multiple languages (even protocol buffers) interacting in complex dependencies, then you should run as fast as you can away from less rigorous Blaze-alikes (Pants, Buck, etc.) straight towards Bazel. Yes, it's complicated, b…

Yeah, I imagine the test is “do you need those things badly enough to dedicate a large portion of a team’s capacity”?

Re: Bazel 2.0

#79

Post by m0zg »

ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

Could you elaborate? I've been using it for a decade, for all my projects big and small, and it's been a _massive_ time saver compared to any of the alternatives. It's fast, well documented, and it doesn't rebuild/retest stuff when it doesn't have to. I've also done multiplatform builds with it, as well as cross-builds to ARM. Not once did I have the need for any "upkeep". At Google there was a team to do that, of course, but even outside Google, even very early on when Bazel was just released, the maintenance is pretty minimal, and the build files are by far the most readable of any build system I have used so far in 20+ years in this industry.

Re: Bazel 2.0

#80

Post by weberc2 »

shrewduser wrote: post #33
zellyn wrote: post #15

Earlier quoted context omitted.

If you are an organization with a large enough codebase (especially if it's in a monorepo) that you need a shared remote cache of build artifacts, or remote build sharding and execution, and have multiple languages (even protocol buffers) interacting in complex dependencies, then you should run as fast as you can away from less rigorous Blaze-alikes (Pants, Buck, etc.) straight towards Bazel. Yes, it's complicated, b…

I'll never understand the fascination with mono repo's.

There are tradeoffs both ways. With multirepos you likely have a dependency hell problem and you often have to submit and release several PRs for otherwise small updates. With monorepos, (if you want reasonable build times) you have to be able to determine what has changed and what needs to build (including tests, etc) as a result. This is technically true of multirepos as well, but the problem is pushed into git and manual process.

Having looked seriously at both options, I think the monorepo world is the right one, but it presently lacks good tooling to sanely model your dependency graph AND create custom build rules while still being affordable for small or medium-sized orgs. Git/hub simply isn’t designed for this kind of modeling and everything I’ve seen built atop it is either way too manual or a kludge. Maybe the “kludge” solutions are actually reasonable, but my confidence is low.

Bazel is the right idea, but it’s execution disappoints. The documentation is abysmal, last I checked they advertised Python 3 support, but it’s been broken for years with no signs of progress. Building custom rules also looked hopelessly complex (by which I mean, “not something our organization can afford to implement and maintain”) but maybe there’s some undocumented happy path that I’m missing out on? These things seem easy enough to implement. We’re using Pants right now, and for it’s many similar problems (bugs, documentation, poor code base, difficult extensibility), it at least does a passable job at building Python projects.

I’ve thought about it a fair amount, and I think it’s reasonable to build something simpler that might not meet Google’s use case, but would at least enable small and medium sized shops to play the monorepo game.

Post reply on HN