Bazel Release 1.0 • Hacker News Board

Re: Bazel Release 1.0

#31

Post by aiuto » Thu, Oct 10, 2019, 2:44 PM UTC

echelon wrote: post #7

orangepanda wrote: post #5

Did they announce the deprecation date as well? https://killedbygoogle.com/

Bazel is here to stay. Sooo many companies are jumping on this bandwagon [1]. Bazel is better than Maven, Pants... you name it. Think of this like Protobuf or Kubernetes. It's an open source tool used to build things at scale. There will be lots of users and contributors. A cottage industry will spring up, and this will grow well beyond Google. [1] https://github.com/bazelbuild/bazel/wiki/Bazel-Users

The cottage industry is already springing up. There are a few firms offering Bazel consulting and training. https://bazel.build/experts.html

Re: Bazel Release 1.0

#32

Post by klodolph » Thu, Oct 10, 2019, 2:45 PM UTC

ses1984 wrote: post #19

klodolph wrote: post #11

Earlier quoted context omitted.

Yes. My guess is that over a long enough period of time, the internal build system will migrate to Bazel. But I don’t think it will happen soon. Large migrations are always a pain, but Bazel does make it easier (since you can isolate dependencies very well and migrate bottom-up). I don’t work there, but I have talked to Googlers working on build systems.

I want to try this with a monorepo codebase now but every time I try to get started I feel overwhelmed. I'm trying to sell my team on it, but none of us has experience with bazel. I'm trying to figure out how to do a small poc where we migrate one intermediate thing in the monorepo to bazel and try to prove out how it can take over everything.

I have personally done this.

- You are going to screw things up a couple times. The documentation for Bazel is not always clear, but you can usually find examples or explanations of complicated stuff on forums somewhere.

- Start with a leaf dependency, something in your codebase that doesn’t depend on anything else. Then work your way up. Just write a WORKSPACE + BUILD.bazel in your root, and then put a BUILD.bazel in the directory for the dependency you are going to work on.

- Look at examples like Tensor Flow, especially for how to handle third-party dependencies (although Tensor Flow is going to do it in a more complicated way).

- Migrate your tests as you go.

- Just run "bazel build //...:all" or "bazel test //...:all" from your project root as you go to make sure things don’t break.

- Undoubtedly it will take a while to develop a good mental model of how Bazel works. For fun, try looking around in the output directories, or look at the sandboxes it creates.

Re: Bazel Release 1.0

#33

Post by paulddraper » Thu, Oct 10, 2019, 2:45 PM UTC

mosselman wrote: post #12

What is it? What can I use this for?

Polyglot build system (a la make), designed by Google for large code bases with:

* Assured reproducibility via sandboxing

* Distributed caching

* Distributed execution (experimental)

* Support for long-lived worker processes

* Static analysis of build dependencies

* Uniform CLI for builds and tests

Build definitions and extensions are written in Starlark, a subset of Python.

If you work in a large repo, especially one with multiple languages, you should be interested in Bazel.

Many of Google's OSS projects now build with Bazel (TensorFlow, K8s, Angular).

Buck and Pants are similar tools by Facebook and Twitter respectively, inspired by Bazel's closed source predecessor Blaze.

Re: Bazel Release 1.0

#34

Post by gfunk911 » Thu, Oct 10, 2019, 2:48 PM UTC

klodolph wrote: post #28

neves wrote: post #20

My company uses Java and Javascript, our build system is Maven. It starts the npm/yarn build process. We have hundreds of projects in it. I don't like the tooks, but would it be worth the trouble to change to Bazel?

Bazel has good support for both languages. My personal experience is with the JavaScript + Rollup (or TypeScript + Rollup) rules for Bazel. There are rules for Bazel + Yarn integration and although I use them, I’m not really qualified to give an opinion. With the TypeScript projects I work on, you have an ordinary yarn.lock and some extra Bazel rules in WORKSPACE to install the packages, and then you use some Bazel r…

What helped you push through the steep learning curve when you started? Asking cause I was excited recently to try Bazel specifically for a Typescript monorepo, and the learning curve crushed me.

Re: Bazel Release 1.0

#35

Post by habitue » Thu, Oct 10, 2019, 2:58 PM UTC

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0).

The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplementations. The rust packaging rules for bazel reimplement a subset of cargo's features from scratch. The docker rules reimplement image building from scratch (they don't actually use docker). The (Google maintained) python rules shell out to pip, but it's got a ton of problems, some packages are unbuildable, and it busts the cache constantly and redownloads everything.

If you're using C++ or Java, I can heartily recommend Bazel as an improvement to your current tool. If you're using anything else, hold off until the ecosystem is more mature.

I can believe all of these reimplementations are worth it for hermeticity, but I seriously doubt most shops need the extreme hermeticity Google does. It's a thing that really matters at gargantuan scale.

Re: Bazel Release 1.0

#36

Post by setheron » Thu, Oct 10, 2019, 3:00 PM UTC

I really want to use it but anything beyond the simple example is difficult to migrate to. I must have read the toolchain pages 10x times but still setting up a custom compiler or even different JDK setup is confusing.

Re: Bazel Release 1.0

#37

Post by miles_matthias » Thu, Oct 10, 2019, 3:02 PM UTC

Woo hoo! I got to spend a few days with the Bazel team in the NYC office a few weeks ago and they were really excited about this announcement coming out soon. Congrats!

One of my favorite uses of Bazel is in CI/CD. I built a demo which builds the applications, creates Docker images, and then applies a K8s manifest to a cluster. It's OSS now under the GCP handle: https://github.com/GoogleCloudPlatform/gke-bazel-demo

Happy to answer any questions, public or private (email / website in bio).

Re: Bazel Release 1.0

#38

Post by rjsw » Thu, Oct 10, 2019, 3:04 PM UTC

Is it any easier to port to different operating systems than earlier versions ?

Re: Bazel Release 1.0

#39

Post by klodolph » Thu, Oct 10, 2019, 3:07 PM UTC

habitue wrote: post #35

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…

> The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplementations.

My experience from before Bazel is that reimplementations were the way to go most times you had projects with multiple languages, because the alternatives lead you down dark paths—calling into a separate build system suffers from the same problems as recursive make.

What excites me about 1.0 is the possibility that the third-party rules can mature. Its not too bad if you only need a couple sets of third-party rules but my experience is like yours-when a new Bazel release came out, you had to figure out when to upgrade based on your dependencies on third-party rules. If you had several of these, it made upgrading Bazel infeasible.

Re: Bazel Release 1.0

#40

Post by klodolph » Thu, Oct 10, 2019, 3:12 PM UTC

gfunk911 wrote: post #34

klodolph wrote: post #28

Earlier quoted context omitted.

Bazel has good support for both languages. My personal experience is with the JavaScript + Rollup (or TypeScript + Rollup) rules for Bazel. There are rules for Bazel + Yarn integration and although I use them, I’m not really qualified to give an opinion. With the TypeScript projects I work on, you have an ordinary yarn.lock and some extra Bazel rules in WORKSPACE to install the packages, and then you use some Bazel r…

What helped you push through the steep learning curve when you started? Asking cause I was excited recently to try Bazel specifically for a Typescript monorepo, and the learning curve crushed me.

To be honest I had written some custom build systems and spent extensive time working on the problem. So a lot of the Bazel features made me go “aha” because they solved a problem I recognized—but the features seem weird if you don’t recognize the problem you’re solving.

What helps is to understand the separate phases of the Bazel build process and look at other Bazel repositories.

To me it’s not as bad as e.g. the mess I remember going through with TypeScript back when you had to write a lot of your own types for libraries you used.