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

41–50 of 117 posts

Re: Bazel 2.0

#41

Post by tibiahurried »

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.

I am sure you will when you will end up working in a huge organization with intricated and heterogeneous projects/teams interdependencies.

You will soon experience:

- dependencies hell due to transitive and conflicting dependencies

- one back-incompatible change in some obscure library end up breaking some other unknown service that happens to transitively depend and it

- the entire codebase will become a mess due to inconsistent code styles and formatting because hey we are developers and we can never agree on anything. Thus each team lead will have its own opinion

- each team will have to maintain its own CI/CD jobs

- heterogeneous builds: maven, node, sbt, webpack, etc ...

the list goes on ...

All (or most of) this mess is solved by centralizing the codebase in a monorepo.

Re: Bazel 2.0

#42

Post by jingwen »

jsolson wrote: post #9
zegl wrote: post #4

Earlier quoted context omitted.

I can’t understand why the Bazel team hasn’t learnt from Go team how to handle breaking changes. Bazel is an amazing piece of tech, but it can definitely be a lot of work to keep up to date.

I don't know the team specifically, but I suspect the difference comes down in part to Go open sourcing early in development, thus finding a bunch of the rough edges that exist outside Google's walled garden early in the project's life when there wasn't much compatibility _to_ break. Blaze was a mature project within Google for years before Bazel was opened up. Many of the breaking changes seem to be taking one-offs…

> The net result is a Bazel (and Blaze) that are less burdened by the baggage of legacy, but the cost is a faster treadmill to keep pace with changes.

(I work on Bazel.)

This is accurate. A few of the biggest breaking change themes are:

1) Converting functionality linked within the Bazel binary into the extensibility mechanism implemented in Starlark. An example includes converting the native Java, C++, Android, Python, Protobuf, Obj-C and packaging rules into rules_java, rules_cc, etc. Many languages now are already implemented exclusively in Starlark. See rules_scala, rules_rust, rules_go and rules_haskell.

2) Starlark and Build API cleanups that accumulated over organic growth and development within Google for the past decade.

3) New build system features to support seamless integration with other build systems and package managers.

Re: Bazel 2.0

#43

Post by dehrmann »

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…

I was talking with an engineer who saw two people burn out over Bazel, though the specific gripe was with Scala support. I'd expect first-class languages at Google (C++, Java, Python, Go) to get better support.

Re: Bazel 2.0

#44

Post by jacquesm »

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…

Seconded. Any org with less than a few 100 engineers (and many with that many and more) would do better to stay away from this. I've had the dubious honor of using it for one project and to me the slogan is 'tools should work, not require attention', rather than the opposite. Bazel will require a lot of your attention and for smaller companies that could easily be a big percentage of their available capacity.

For very large organizations with the capability of assigning one or more teams to tooling it may very well be the right choice.

Re: Bazel 2.0

#45

Post by dehrmann »

serverholic wrote: post #40
shrewduser wrote: post #33

Earlier quoted context omitted.

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

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.

Re: Bazel 2.0

#46

Post by taeric »

serverholic wrote: post #40
shrewduser wrote: post #33

Earlier quoted context omitted.

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

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

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.

Re: Bazel 2.0

#47

Post by arianvanp »

moomin wrote: post #38
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…

Nix also exists...

Nix is not (yet) suitable for fine-grained (read file level) build targets though due to lack of recursive nix and content addressed store. This means you don't have early cut off and mass rebuilds if only one file changes; for example. Both are being worked on actively though.

Re: Bazel 2.0

#48

Post by arianvanp »

gravypod wrote: post #16
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…

I've only experienced issues when using bazel with third party package management systems. If you can own all of your source it, and it's descendants, are easily my favorite build systems. It's features complement modern software development in a very ergonomic way: uniform build language, API for learning about your source, testing your entire code base in every language with one command, hermetic and reproducible b…

I would advice checking out https://www.tweag.io/posts/2018-03-15-bazel-nix.html for external dependencies

Re: Bazel 2.0

#50

Post by serverholic »

taeric wrote: post #46
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.

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.
Post reply on HN