Didn’t this just hit 1.0?
Yes, 2 months ago.
Bazel 2.0
31–40 of 117 posts
Re: Bazel 2.0
#32I’ll jump here to say that Bazel 1 was awesome, and I’m looking forward to trying out Bazel 2.
I was wondering how to make sure Bazel doesn’t rebuild something it has built previously? (Caching)
Re: Bazel 2.0
#33For 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…
I'll never understand the fascination with mono repo's.
Re: Bazel 2.0
#34I miss the days when JavaScript frameworks could be built with a simple npm install and executing a Grunt/Gulp file. Now to build Angular I need Yarn, Java, Bazel, and hundreds of megabytes of additional tooling downloaded by the build script. On a slow connection it takes ages to download everything, and even then the build often fails (on Windows I have yet to get it working successfully). Edit: I'm referring to bu…
I miss the days when JavaScript frameworks required only a script tag.
Re: Bazel 2.0
#35Earlier quoted context omitted.
That "changed some corner cases that likely won't affect you" and "rewrite it all" looks the same in SemVer makes it next to useless, not that any other system would be better. We just shouldn't have any expectations about version numbers conveying much information.
Yes, and this is my biggest frustration with semver. it adds something valuable by communicating breaking changes, but it loses something else valuable, signaling the magnitude of the changes. Hopefully in the coming years something will eclipse semver which solves both problems sufficiently. I don't know of any candidates offhand though.
Don't know how you could reliably do it.
You could do something like "LoC from last version" + SemVer.
So, 1.2.3k to indicate Major 1, minor 2, 3k lines of code changed from 1.1. It would also possibly be a good way to say "2.0.3" meaning, we moved from 1.2 to 2.0, but only changed 3 lines of code. The breaking change is likely not going to affect you but it is there.
That might make magnitude changes easier to communicate.
I'm not sure how useful this would be for automated build tools though. Would you set bounds on how far drift would go before automated updates?
Re: Bazel 2.0
#36I’ll jump here to say that Bazel 1 was awesome, and I’m looking forward to trying out Bazel 2. I was wondering how to make sure Bazel doesn’t rebuild something it has built previously? (Caching)
There are many layers of caching within Bazel (remote/local, inmemory/disk), but the central functional incremental engine is called Skyframe [1]. Almost every computation within Bazel that can be incrementally executed is managed in this engine.
Re: Bazel 2.0
#37For 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…
Pretty much the same experience. 2y old monorepo company with >150 engineers now, being slowed down by hacks upon hacks in the usage of the bazel build system with around 5 people at the company understanding how bazel works. And those people are discouraged quickly when trying to improve things because of the shear brittleness of the existing build files and "optionated" approaches in the community that don't quite…
Indeed. If Bazel had a slogan, it would be "Everyone who doesn't do things my way is stupid". That's probably great within Google, but trying to integrate it into a company that has already made conflicting decisions (for good reasons) is hell.
Re: Bazel 2.0
#38For 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…
Nix also exists...
Re: Bazel 2.0
#39For 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…
> 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.
Re: Bazel 2.0
#40Earlier 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.
Well for one you can commit to multiple projects in a single PR. Makes coordinating changes across projects much easier.