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

Bazel Release 1.0

github.com

Post reply on HN
Print view View original

121–130 of 180 posts

Re: Bazel Release 1.0

#121

Post by adev_ »

I am going to be hated and downvoted for that but let's go...

Bazel, like Bucks and other, try to bring on table a build system / deployment system that is multi-language, multi-platform and developer oriented. A holy Graal that many developer ( like me ) looked for decade and that many (large) organizations more or less tried to do one day (and most failed)

It is a good idea. It is a required tool to improve productivity. However, if the idea is good on paper, in the implementation, Bazel is damn wrong.

- Bazel is centered around "mono-repo" culture, making it much harder to integrated with multi-source, multi-repo, multi-version projects like many of us have. If I have no doubt that it is great at Google, the external world is not google.

- Bazel is made in JAVA, requires the JVM and this is a problem. That make Bazel not a "light" tool easy to deploy in a fresh VM or in a container.

- Bazel mix the concepts Build System ( like Make, ant, co ) and Deployment System like ( rpm, pkgsrc, etc). That makes Bazel pretty hard to integrate with projects that have existing build system, and almost impossible to integrate INSIDE an other Deployment System (usual package manager, deployment pipeline). The problem that Bazel faces with some languages ( python, go ) is a cause of that.

- Bazel venerates and follows the cult of "DO NOT INSTALL": compile and execute in workspace, there is no "make install", not installation phase. If "convenient" in mono-repo, this is often a nightmare because the boundary between components can be easily violated... and you finish by having many project that use internal headers or interface.

- Bazel makes mandatory ( almost ) to have internet to compile. This is a problem, a major problem in many organization (like mine) where downloading random source and binary from the Web is not acceptable for security reasons. Try to run Bazel in a sandbox.... and cry.

- Related to what I said before, Bazel mixes Build system and Deployment system. Doing so, it makes the same mistake that many "language specific" package manager and make uselessly hard to depend on an already installed, local library / component.

- And finally, last but not least... The options.... Bazel throw away 30 years of conventions / naming from the ( GNU / BSD world ) to create its own.... That make the learning curve difficult... Specially with a (up to recently) very sparse and outdated documentation.

I have no doubt that inside Google or Facebook, Bazel or Bucks are amazing.But they have been released too late for the external world in my mind.

Nowadays platform independant package managers like spack (https://github.com/spack/spack), Nix (https://nixos.org/nix/), GUIX (http://guix.gnu.org/) gives 95% of the advantages of Bazel without the pains of it.

Re: Bazel Release 1.0

#122

Post by christiangruber »

swsieber wrote: post #115
oweiler wrote: post #109

Earlier quoted context omitted.

I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.

I very much doubt that it's faster than Gradle, but Gradle does do quite a bit more than Gradle.

It's not an absolute, but a contextual thing. For a clean build, on a single machine, under normal circumstances, gradle will often outperform bazel, because bazel pays a cost for isolation, parallelism infrastructure, and trying to max out your machine. OTOH, the abi-based compilation-avoidance, higher sensitivity to caching opportunities, and parallelism can make incremental builds much much faster on Bazel. Add in test-result-caching for non-flaky tests, and it's really a solid win for builds that don't invalidate most of the build graph.

So it depends on (a) the shape of your graph, and (b) the nature of the change being built (e.g., does it invalidate a core library and all its downstream, or is it close to the app?).

The other thing is remote build execution - the high focus on hermetic builds and parallelism makes building on a cluster of build workers extremely powerful, reducing build times, reducing load on developer machines, etc. And there are out-of-the-box solutions, initially from google on GCP to let you do this yourself.

So... is bazel faster? Hell yeah, in some situations. Kinda in others. Not in some others. You need to think through what your development model is, your scale, how you construct (or want to construct) your build graphs, isolation of components, etc.

Re: Bazel Release 1.0

#123

Post by wasyl »

aidenn0 wrote: post #63

If android switches to bazel now that bazel is 1.0 does that mean we can switch from a completely undocumented tool to a poorly documented tool?

> completely undocumented tool

Gradle is far from "completely undocumented". Unless you mean Android Gradle Plugin, which surprisingly _is_ somewhat documented, although the docs are tough to accidentaly just stumble by

Re: Bazel Release 1.0

#124

Post by wasyl »

steeve wrote: post #74

I've been using it for over almost two years on a 5 languages iOS/Android project, and then on everything I could. Congrats to the team!

Nice! I've been considering trying out Bazel for an Android project but didn't get around to it yet. How is the IDE support (Android Studio and/or IntelliJ)? And how is actual Android support in Bazel, for example in terms of feature modules, app bundles, DataBinding (that I guess is supported as a regular annotation processor) and third party plugins like Firebase? How much of a dealbreaker is it if I have to use a complex 3rd party Gradle plugin that I wouldn't want to rewrite for Bazel?

Re: Bazel Release 1.0

#125

Post by lhorie »

mdaniel wrote: post #119
lhorie wrote: post #82

Earlier quoted context omitted.

I started by going through the Java tutorial[1] to get a feel for it. It's fairly approachable and you don't actually need any Java knowledge. Once you familiarize yourself with the concept of rules and targets, you can follow the instructions for whichever ruleset you want to use. The official one for JS is rules_nodejs[2] Another thing that really helped me cement my understanding of Bazel was to deep dive into Sta…

Give the title of this thread, don't you mean https://docs.bazel.build/versions/1.0.0/tutorial/java.html ?

Oh, yeah, good catch

Re: Bazel Release 1.0

#126

Post by baylisscg »

ceronman wrote: post #114
mrighele wrote: post #77

Earlier quoted context omitted.

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

I've worked with both and while Bazel definetely has a learning curve, mostly because is very different than Maven and Gradle, I actually find it considerably simpler than those two. Maven dependency management is really complex, and I'm tired of dealing with dependency hell. And Gradle doubles down on Maven complexity where you stop having declarative XML config and instead have actual Groovy/Kotlin programs. So, pl…

Speaking as someone who just got bitten by Maven’s dependency resolution now only building broken artefacts. (Sub-dependency’s dependency is loose enough to pull in a version built with an incompatible JDK) I prefer Bazel

Re: Bazel Release 1.0

#128

Post by thundergolfer »

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…

They’re underinvesting in their Python story in my opinion.

To my knowledge rules_python still doesn’t support pip3 installs, and from browsing Github, Twitter, and the Bazel Slack it seems everyone is reimplementing their own package management integration because the default is so undercooked.

Right now rules_pygen is the best open source option, but it isn’t fully featured and was broken by Bazel 0.28.

Re: Bazel Release 1.0

#129

Post by thundergolfer »

weberc2 wrote: post #80
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…

> but the ecosystem around Bazel is quite bad at the moment I've noticed this as well. I'd love to use Bazel for our Python 3 project, but as far as I can tell, the advertised Python 3 support doesn't actually work. There are several issues filed for this, but apparently no progress since 2018. Some people reported workarounds, but none that I could reproduce. I believe the core is solid, but language support feels a…

Python support is very much alpha. We use rules_python and the “reported workarounds” include forking rules_python, reimplementing a Bazel pip package manager integration, and adding a few twists to your Python codebase to handle Bazel idiosyncrasies.

It’s dozens of hours of work, and even then you quite easily can find yourself not enjoying Bazel’s caching features because of pip wheel being non-deterministic. It’s been a hard road.

Re: Bazel Release 1.0

#130

Post by weberc2 »

jcelerier wrote: post #110
weberc2 wrote: post #87

Earlier quoted context omitted.

> Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. I simply don't have time to write a program in a slow, stringly-typed, ad hoc DSL just to build my actual program.

> It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. most projects are using CMake nowadays : https://www.jetbrains.com/research/devecosystem-2018/cpp/

Most _C++_ projects are using CMake, but it has virtually no adoption among other mainstream languages, and given most open source is not C++, CMake definitely doesn't have any strong share of the open source market.
Post reply on HN