[HN Gopher] When to use Bazel?
___________________________________________________________________
When to use Bazel?
Author : jvolkman
Score : 100 points
Date : 2022-09-13 18:46 UTC (4 hours ago)
(HTM) web link (earthly.dev)
(TXT) w3m dump (earthly.dev)
| cstrahan wrote:
| There's an issue I reported (along with a proof of concept fix)
| over 4 years ago, that has yet to be fixed: building a mixed
| source project containing Go & C++ & C++ protocol buffers results
| in silently broken binaries as rules_go will happily _not_
| forward along the linker arguments that the C++ build targets
| (the protobuf ones, using the built in C++ rules) declare.
|
| See https://github.com/bazelbuild/rules_go/issues/1486
|
| Not very confidence inspiring when Google's build system falls
| over when you combine three technologies that are used commonly
| throughout Google's code base (two of which were _created_ by
| Google).
|
| If you're Google, sure, use Bazel. Otherwise, I wouldn't
| recommend it. Google will cater to their needs and their needs
| only -- putting the code out in the open means you get the
| privilege of sharing in their tech debt, and if something isn't
| working, you can contribute your labor to them for free.
|
| No thanks :)
| rjsw wrote:
| Unless it becomes easier to port to a new operating system,
| never.
| mplewis9z wrote:
| Personally, I've found Bazel's tooling and dependency management
| to be extremely aggressive at pushing you to online-only
| development as your project scales in size. A company I worked
| for that used it lost multiple person-days for every engineer
| they had when Covid hit and the VPN went to crap.
|
| It's great at being able to offload work to a remote server, but
| in my opinion that should never be the only way you can get work
| done. Local development should always be the default, with remote
| execution being an _option_ when available.
| trzy wrote:
| Last year I tried doing a side project with a talented ex-Google
| buddy who insisted we set up Bazel to replace my simple Makefile.
| Three weeks later it still wasn't working on my Windows box. We
| had a mixed Python and C++ code base and I like to use MinGW64
| gcc on Windows. He blamed Windows and tried to get me to switch
| to Mac (no thanks, lol) and eventually he lost interest and gave
| up. The project went on to win an OpenCV funded competition and
| became the basis of a startup -- good job, GNU Make!
|
| So the answer IMHO to "when to use Bazel" is "never" :)
| dbt00 wrote:
| I've used bazel at medium size (100+ engineers, multiple
| languages) and tried to use it at a small size (20 engineers,
| almost all go with a tiny bit of C) and I think the "never" and
| "unless there's no other way" answers from this interview are
| pretty good.
| hot_gril wrote:
| In general, if someone wants to beef up the tooling in my
| project that I know is fine to begin with, I still say "I don't
| mind, go ahead, but I will continue using my old tooling until
| yours works with no regression." Half the time, they abandon
| it. I don't even know how Bazel works cause I've never felt
| enough pain with makefiles etc to research an alternative.
|
| Also, Google tooling knowledge doesn't transfer very well to
| outside projects. Everything is special on the inside there.
| They use an internal version of Bazel called Blaze that's
| totally integrated with everything, with entire teams dedicated
| to the tooling, and only a few officially supported programming
| languages, so of course it works smoothly.
| moosedev wrote:
| I used it for several years inside Google, and TBH it was
| often painful in the ways external users have described in
| this thread. When I was doing something very "normal" from
| the point of view of Google's monolithic codebase, i.e.
| targeting a C++ binary intended to run on Google's
| distributed computing platform, I found it smooth enough, if
| awfully verbose. When I was doing something less vanilla, but
| not necessarily uncommon, e.g. targeting Android, iOS,
| Windows, it was painful, and I spent a lot of time working
| around it or understanding the chains/mountains of clever
| things others had built to work around it.
|
| I understood some of the design decisions and tradeoffs for
| why it works the way it does, but I didn't like it. I
| certainly wouldn't reach for it for a personal project.
| Possibly I still just didn't "get it". I've used dozens* of
| build systems at this point, but hey.
|
| * possibly exaggerating
| dessant wrote:
| > Google tooling knowledge doesn't transfer very well to
| outside projects.
|
| A good number of their open source projects fall apart in
| real-world use. If you visit their repositories you'll often
| get the sense that beyond working on interesting problems,
| their engineers have no desire to properly maintain these
| projects for the next few years. The gamble of relying on a
| Google product unfortunately also applies to their open
| source projects.
| phist_mcgee wrote:
| Maybe that's because the average tenure at google is so
| short?
| thayne wrote:
| Bazel probably wasn't a good fit for that project, especially
| if your makefile was simple.
|
| But where it does work well, is when you have a large complex
| codebase in a monorepo, and you need reliable caching to keep
| build times down.
| lhorie wrote:
| I mean, Python (moreso its ecosystem) is notoriously difficult
| to get working w/ Bazel idiomatically. Bazel is advertised as a
| language agnostic system (and to be fair, it's better at it
| than, say, Buck), but in practice it tends to work better w/
| stacks that already have some degree of hermeticity (Go, Java),
| whereas YMMV very much with the more loosey-goosey stacks
| (Python, JS).
|
| IMHO, Bazel is a classic example of Conway's law[0], and it
| falls squarely in the "big corp" class of software. You have to
| be running into issues like 6+ digit CI compute costs or
| latency SLOs in hundreds-of-teams monorepos before Bazel really
| starts to make sense as a potential technical solution.
|
| [0] https://en.wikipedia.org/wiki/Conway%27s_law
| IshKebab wrote:
| That's like saying you should never build a house with concrete
| foundations because they take so long to dig and pour and the
| first layer of bricks doesn't need them anyway!
|
| Get back to me when you work for a company with a monorepo that
| has to build and test _everything_ in CI for every change
| (taking something like 200 CPU hours) because they didn 't have
| the foresight to use Bazel.
| hot_gril wrote:
| Software development isn't housing development. You lay a
| concrete foundation knowing exactly what is being built on
| top. The typical way of developing software is like adding
| stories to your house until it falls over, then rebuilding it
| stronger, which is perfectly fine in the software world.
| Otherwise things get overengineered.
|
| In practical terms, the makefile or whatever is usually good
| enough.
| drewcoo wrote:
| > company with a monorepo that has to build and test
| everything in CI for every change
|
| That smells like covering up an architecture problem (tight
| coupling) with a build tool. Not a recipe for success.
| deathanatos wrote:
| I don't think that's actually the case. Bazel, AIUI,
| understands the entire dependency tree _and can cache steps
| effectively_ , which a Makefile cannot (alone) do. (You
| could certainly build it into one.)
|
| CI tooling is orthogonal; your CI tooling can invoke Bazel
| or Makefile+custom caching, it wouldn't really matter. But
| the problem in CI is that you lack state; whereas a
| developer's machine might e.g., have a bunch of .o files
| from a previous build, CI will be starting from a clean
| slate1. So builds take longer. My understanding of Bazel is
| that it has decent support for caching and can thus makes
| those rebuilds a lot faster, which it has b/c it
| understands exactly the inputs to the steps at hand.
| (Which, if you write your own caching layer, you'd have to
| figure out.)
|
| ... but ... I've also seen the same thing the top commenter
| has, with Bazel: endless suggestions to use Bazel ... but
| migrating a large existing codebase is _pain_ , and if
| you're not willing to put your work where your mouth is ...
| then the status quo prevails.
|
| 1While here CI lacking state is a sort of negative b/c of
| the time we need to rebuild it, normally, I think this is a
| good thing: it means you're constantly verifying you can
| build from scratch. Or, at least, something close to
| scratch, modulo things like vendoring. (I.e., if you do an
| "apt-get" from Ubuntu's servers in your CI pipeline ...
| well ... your build obviously isn't quite from scratch.)
| hot_gril wrote:
| Google uses a monorepo intentionally, and for good reasons.
| They're also a massive company. For them, a complex build
| system makes sense... and even that system isn't exactly
| Bazel.
| yamtaddle wrote:
| My experience is that Windows is a constant source of headaches
| if you're supporting development and builds on multiple
| platforms and trying not to just write every build-related
| thing twice, Bazel or no Bazel. Likelihood of it being a PITA
| goes up fast the more complex the build & tools (probably why
| Make did better than Bazel).
|
| I assume it's OK if it's your only platform--though I got my
| programming start on Windows, with open-source languages, and
| distinctly recall how managing the same tools and builds got
| _way_ easier and more reliable when I switched to Linux.
| Luckily WSL2 is getting semi-decent and can call out to Windows
| tools, so it 's getting easier to standardize on one or another
| unixy scripting language for glue, even if some of your tools
| on Windows are native.
|
| Part of the trouble with it, though, is that there are multiple
| ways to end up with some kind of linux-ish environment on it,
| and that all of them introduce quirks or oddities. You end up
| having to wrestle with stupid questions like "which copy of
| OpenSSH is this tool using?" It's probably less-bad if you're
| in a position to strictly dictate what Windows dev machines
| have installed on them, I suppose. Git is installed, but only
| with options X, Y, and Z checked, no other configurations
| allowed; WSL2 is installed and has packages A, B, and C
| installed; and so on, crucially preventing the installation of
| _other_ things that might try to pile on more weirdness and
| unpredictability.
|
| Those kinds of messes are _possible_ on macOS or Linux or
| FreeBSD or what have you, but generally don 't happen. I think
| it happens on Windows because every tool's trying to vendor in
| various Linux-compat dependencies rather than force a
| particular system configuration on users, or having to try to
| deal with whatever maybe-not-actually-compatible similar tools
| the user has installed. So they vendor them in to reduce
| friction and the rate of spurious bug reports. Basically, the
| authors of these tools are seeing the same problems as anyone
| trying to configure cross-platform development with Windows in
| the mix, and are throwing up their hands and vendoring in their
| deps, which compounds the problem for anyone trying to
| coordinate several such tools because there's a tendency for
| everything to end up with weird configurations that don't play
| well together.
| trzy wrote:
| All excellent points but Windows is a very widely used
| platform (perhaps the most widely used, by some metrics) and
| it's actually quite nice for development. It's hard to take
| tools seriously that don't work on it.
|
| Unpopular opinion but I think the Unix approach of lots of
| little tools with arcane configuration files all blaming each
| other sucks. I get why it exists, why it became popular, and
| why it remains popular in some scenarios, but I don't feel
| beholden to it.
| yamtaddle wrote:
| Right--in some sense it's not really Windows' _fault_ that
| something like Git is barely-portable and relies on a rube-
| goldberg-machine pile of scripts and binaries in several
| languages with the result that it has to ship half a unix
| environment to work somewhere that 's very non-unix, or
| that open-source software in general treats Windows the way
| web developers treat Firefox.
|
| OTOH, in practice, if you're using a lot of open source
| tools and have developers working on every single halfway-
| plausible OS _except_ windows, things are probably pretty
| OK, but then you throw Windows in the mix and suddenly the
| time you spend supporting your builds & tools shoots way
| up. That makes it _feel_ like it 's Windows' fault.
| cma wrote:
| Android is an even bigger pain, suddenly you have to call
| Java code just to map memory and can't even have a simple
| C api for something as low level as that.
| yamtaddle wrote:
| As a development and/or build environment? Never used it
| that way, myself. Agree that as a build _target_ , and as
| far as its various first-party developer-facing features
| and libraries and SDKs and such go, it's got weirdly-many
| rough edges and half-baked-but-heavily-promoted junk for
| such a major platform.
| moonchrome wrote:
| >and it's actually quite nice for development
|
| If we are talking about stuff like backend web development
| then I'd say no, it's actually a pain to work with - few
| people bother deploying to Windows these days, many
| libraries/frameworks treat it like a second class citizen,
| tooling doesn't translate well (or at all).
|
| Even frontend webdev is very unixy due to node/npm and
| popularity of Macs in that space.
|
| When you're talking about OpenCV, GPU related things, game
| dev then the situation is reversed.
|
| So it highly depends on what you're developing.
| vbezhenar wrote:
| I think we each live in our own bubbles. I see very few
| people on macs or linuxes, almost everyone uses Windows
| and they're fine with web development. What's so unixy
| about node/npm? They feel like very good windows
| citizens.
| Cu3PO42 wrote:
| For the most part npm has worked for me on Windows, but
| it's so incredibly slow compared to even npm in a Linux
| VM on the same host. I understand this is mostly due to
| FS overhead related to a multitude of small files.
|
| Obviously this isn't a deal breaker in most situations,
| but it is a bit annoying. I've observed similar
| performance problems running Webpack on Windows in the
| past.
| hot_gril wrote:
| > It's hard to take tools seriously that don't work on it.
|
| In my experience, most software development tools don't
| work on it, at least not as well as on Unix-like systems.
| But I'm not a game dev.
| londons_explore wrote:
| Don't use tools outside what they're designed for...
|
| Specifically, Bazel is really at home with Java/C++ and Linux.
| Sure, it kinda works elsewhere, but you should be considering
| other options.
| badoongi wrote:
| My take - Avoid Bazel as long as you can, for most companies the
| codebase is not big enough to actually need distributed builds,
| if you've hit this problem Bazel is probably the best thing you
| can do today, if you're that big you can probably spare the few
| dozen headcount needed to make Bazel experience in your company
| solid.
|
| Bazel takes on dependency management, which is probably an
| improvement for a C++ codebase where there is no de-facto package
| manager. For modern languages like golang where a package manager
| is widely adopted by the community it's usually just a pain. e.g
| Bazel's offering for golang relies on generating "Bazel
| configurations" for the repositories to fetch, this alternative
| definition of dependencies is not what all the existing go
| tooling are expecting, and so to get the dev tooling working
| properly you end up generating one configuration from the other
| having 2 sources of truth, and pains when there's somehow a
| mismatch.
|
| Bazel hermeticity is very nice in theory, in practice many of the
| existing toolchains used by companies that are using Bazel are
| non-hermetic, resulting in many companies stuck in the process of
| "migration to Bazel remote execution" forever.
|
| Blaze works well in Google's monorepo where all the dependencies
| are checked in (vendored), the WORKSPACE file was an afterthought
| when it was opensourced, and the whole process of fetching remote
| dependencies in practice becomes a pain for big monorepos (I just
| want to build this small golang utility, `bazel build
| //simple:simple` and you end up waiting for a whole bunch of
| python dependencies you don't need to be downloaded).
|
| And this is all before talking about Javascript, if your JS
| codebase wasn't originally designed the way Bazel expects it
| you're probably up for some fun.
| intellix wrote:
| as an angular developer, Bazel was promised to replace webpack
| behind the scenes and suddenly everything would get fast and all
| our problems would be solved. Months... Years went by until
| eventually it became an opt-in solution and I guess they just
| gave up trying to use it.
| setheron wrote:
| I can never wrap my head around writing a tool chain in bazel
| [deleted]
| grahamplace wrote:
| Worth pointing out that Build Buddy (YC W20) has an enterprise
| Bazel product that tries to make some of the management of Bazel
| easier.
|
| I haven't used it myself so no commentary, I just have a friend
| who started there recently so it's on my radar
|
| https://www.buildbuddy.io/
| https://www.ycombinator.com/companies/buildbuddy
| xwowsersx wrote:
| Only tangentially related, but can someone give me the pitch for
| Earthly? I think I'm just missing something basic.
|
| Our CI consists of tests, builds and deployments (all docker
| containers) that are kicked off in bitbucket pipelines. Is there
| some way that either our local development or CI builds can be
| improved by using earthly? Appreciate any info!
| choeger wrote:
| Very nice work. Worth a read!
| an_d_rew wrote:
| I will quote my past self
| (https://news.ycombinator.com/item?id=26064845)
|
| We use Bazel's rules_docker as well, and I would caution someone
| evaluating it with a note from out experience.
|
| What Bazel does well (and as well as Bazel fits your use-case)
| Bazel does extremely well and is a reproducible joy to use.
|
| But if you stray off that path even a tiny bit, you're often in
| for a surprisingly inexplicable, unavoidable, far-reaching pain.
|
| For example, rules_docker is amazing at laying down files in a
| known base image. Everything is timestamped to the 1970 unix
| epoch, for reproducibility, but hey, it's a bit-perfect
| reproduction.
|
| Need to run one teensy executable to do even the smallest thing
| that's trivial with a Dockerfile? Bazel mist create the image
| transfer it to a docker daemon, run the command, transfer it
| back... your 1 kb change just took 5 minutes and 36 gb of data
| being tarred, gzipped, and flung around (hopefully-the-local)
| network.
|
| It may not be a dealbreaker, and you may not care, but be
| forewarned that these little surprises creep up fairly ofen from
| unexpected quarters!
|
| Edit: after 2-ish years of Bazel, I would say that for 99% of
| developers and organizations, the most likely answer is "never".
| miiiiiike wrote:
| I lost a month learning Bazel last year. Never again. Here's a
| challenge: Create a Bazel built Angular library using only the
| publicly available documentation. Here, I'll save you some time:
| You can't.
|
| What documentation exists is flawed and what isn't flawed has
| massive holes. It was so bad that I had to ask a few Google
| employees if there was secret internal documentation somewhere.
| There isn't, and, they almost all hated using it as well.
|
| I went back to Make and had the whole repo building in an
| afternoon.
|
| Bazel is a great idea but like most other Google OSS projects it
| doesn't have strong enough documentation to form a community or
| enough of a community to create good docs.
|
| Even if I brute forced my way into using Bazel, I couldn't ask an
| employee to learn it.
|
| I hear that Blaze is much easier to work with.
| [deleted]
| dietrichepp wrote:
| I've been using Bazel for side projects these days, including
| small retro game projects for old game consoles. The entry price
| was high, but it works so well I have a hard time imagining
| working without it.
|
| For retro game projects, the core of your game might be written
| in C or C++, which you want cross-compiled. That's easily within
| reach of stuff like makefiles. But then I start adding a bunch of
| custom tooling--I want to write tools that process sprites,
| audio, or 3D models. These days I tend to write those tools in
| Go. I'm also working with other people, and I want to be able to
| cross-compile these tools for Windows, even though I'm developing
| on Linux or macOS.
|
| My Bazel repository will download the ARM toolchain automatically
| and do everything it needs to build the target. I don't really
| need to set up my development environment at all--I just need to
| install Bazel and a C compiler, and Bazel will handle the rest. I
| don't need to install anything else on my system, and the C
| compiler is only needed because I'm using protocol buffers (Bazel
| downloads and compiles protoc automatically).
| synergy20 wrote:
| Makefile can do all that too, without java dependency and
| straightforward to read at any time later, what real extra
| benefit Bazel brings in here.
| kldx wrote:
| Can make do incremental builds based on checksums instead of
| modification time? How about distributing the build across a
| cluster in a language agnostic way?
| jpollock wrote:
| Bazel is more strict about what constitutes a dependency
| change. It doesn't use mtime on the file, it relies on the
| checksum. It also considers the command line flags to be part
| of the cache key.
|
| So, spurious changes (touching a file) will result in a cache
| hit, while hidden changes (changing an environment flag used
| by Make) are caught.
|
| This is particularly important if verifiable builds are
| needed for SoX compliance.
| aaaaaaaaaaab wrote:
| What if I use the __DATE__ macro?
| jvolkman wrote:
| You'll get "redacted"
|
| https://github.com/bazelbuild/bazel/blob/34ce6a23f5a2be58
| bb5...
| jpollock wrote:
| Yes, you can go out of your way to make your builds non-
| deterministic. That should break in Make as well.
|
| I don't know enough about bazel to answer your question
| definitively, but "stamping" is what you want to search
| for.
|
| https://bazel.build/docs/user-manual
| kmarc wrote:
| The better question is, what if you change a comment?
|
| It checksums the preprocessed files, so neither
| `__DATE__`, no comment changes should affect your build
| times.
| jpollock wrote:
| I think __DATE__ without redaction pushes the dependency
| change 1 level down, to the .o file.
|
| The .a/.so/.exe would no longer match the inputs (the .o
| files), causing a re-link.
| vbezhenar wrote:
| Does it re-read every single source file to find out which
| were changed? Sounds like a terrible approach. Or it uses
| mtime first and checksum after that?
| yata69420 wrote:
| The benefit is that it keeps a huge graph of all
| dependencies, so everything from the toolchain through your
| application can be built with hashing and caching. Sort of
| like make, but decentralized and based on hashed file
| contents.
|
| Once you have bazel, you can distribute the workload so that
| you could have thousands of machines each producing artifacts
| to be shared with other build machines.
|
| Then you can set up your dev machine to rely on those caches,
| so your local builds either use everything directly from
| cache or instruct a remote builder to produce the artifact
| for you.
|
| No matter what you change, because the dependencies are
| graphed precisely, you only need to rebuild a very tiny set
| of artifacts impacted by your change.
|
| Of course, this doesn't actually work in practice.
|
| Your builds probably aren't deterministic, so your graph of
| artifacts won't be either, causing lots of stuff to rebuild.
| Also, it may work great for something like Java that produces
| class files, but not provide any caching at all for ruby.
|
| Debugging and supporting it is a full time job for a team of
| engineers that dramatically outweighs the cost of keeping
| your projects sensibly sized.
|
| You might think that as the project gets larger, it's totally
| worth it to use bazel for that sweet caching. But in reality
| the graph construction and querying will become so bloated
| that just figuring out which targets need to rebuilt becomes
| a full time engineering effort that breaks constantly with
| all tooling upgrades.
|
| Also, the plugin ecosystem is just poor.
|
| Bazel is the perfect storm of computer scientists loving big
| graphs, Google exporting an open source project and then
| rebuilding it internally, and inexperienced engineers being
| sold on a tech as being obviously right because all the big
| players use it.
| dietrichepp wrote:
| > Makefile can do all that too,
|
| I guess it's theoretically possible, but why would you do
| this? This sounds like some kind of "I want to prove it can
| be done" project like running a web server on a Commodore 64,
| or making a kitchen knife out of cardboard. Yes, you could
| figure out a way to download and install dependencies using
| Make and Curl, and maybe you could build the same library for
| multiple targets using a bunch of variable expansions,
| possibly by invoking make multiple times, or including the
| same makefile multiple times. Make sucks; it sucks a lot; I'd
| be miserable.
|
| And then if you aren't very careful, you'll end up forgetting
| to declare some dependency, or some flag change will
| invalidate your build but Make won't do anything, or you'll
| make a change to your makefile and forget to clean, and then
| you spend another hour or day debugging some build that was
| made out of stale parts. I've done this before, which is why
| I avoid make for everything but the smallest projects.
|
| > without java dependency
|
| Bazel does not have a Java dependency. I think you might be
| assuming that because Bazel is written in Java, somehow that
| means that Java must be installed on your computer. This is
| not true. Bazel is a self-contained executable you can drop
| in /usr/local/bin.
|
| I really don't understand your perspective here at all. I've
| seen people defend make, but make is full of so many traps
| and gotchas--I wonder how someone could use make and then
| decide that these traps and gotchas are okay. The projects
| that successfully use it tend to be small projects, use
| generated makefiles (automake, cmake, etc), or tend to be a
| bit simpler.
|
| I use make myself, but as a rule of thumb, only for projects
| with a few files.
| ajconway wrote:
| Bazel doesn't have any user-facing java dependency.
|
| > what real extra benefit Bazel brings in here
|
| Builds are hermetic by default, so unless the developer
| chooses to escape the sandbox, everything is guaranteed to
| build on other machines with no additional setup.
|
| (Also, I genuinely hate when I have to manually install build
| dependencies system-wide and pray that there will not be any
| conflicts. Having everything pinned to specific sha256 or git
| hashes by design is a breath of fresh air)
| blueblob wrote:
| I used a M1 Mac to try to build tensorflow and tensorflow-
| text and it is very untrue that everything is guaranteed to
| build on other machines with no additional setup.
|
| The parenthesized comment is funnier to me because I had to
| download a specific bazel version to build.
| jvolkman wrote:
| > The parenthesized comment is funnier to me because I
| had to download a specific bazel version to build.
|
| If you use bazelisk to provide your `bazel` command,
| it'll download the appropriate Bazel version for the repo
| you're trying to build.
|
| https://github.com/bazelbuild/bazelisk
| ajconway wrote:
| That is true, Bazel itself is still evolving, and there
| have been breaking changes between versions. Sometimes
| the required version number is placed in a .bazelversion
| file, which makes Bazelisk your top-level dependency.
|
| I'd expect Tensorflow to have some non-hermetic build
| actions, but if choosing a specific Bazel version was the
| only thing that was required to build it, that's awesome!
| IshKebab wrote:
| The benefits that it brings is the whole reason it exists:
| precise dependency tracking.
|
| That means you can't have missing dependency links ( _very_
| common and hard to debug in Make or CMake for example). You
| can _know_ what outputs a change affects so you can only
| build /test a subset of the project in CI. Incremental builds
| become totally reliable. Etc.
| steeve wrote:
| Trying to learn Bazel by porting an existing project to it is a
| very hard way to get into this amazing tool.
|
| If possible, start fresh.
|
| I don't see myself working without it from now on.
| tdeck wrote:
| The thing is, something like Bazel only pays dividends on a
| large complex project. When you're starting from scratch it's
| unlikely you'll have any problems that Bazel helps to solve,
| but you'll be spending a lot of time on the ceremony of setting
| it up.
| EdSchouten wrote:
| Regardless of whether you should use Bazel or not, my hope is
| that any future build systems attempt to adopt Bazel's remote
| execution protocol (or at least a protocol that is similar in
| spirit):
|
| https://github.com/bazelbuild/remote-apis
|
| In my opinion the protocol is fairly well designed.
| lxe wrote:
| When not to use Bazel: when attempting to shoehorn it into an
| existing JavaScript monorepo.
| spion wrote:
| Yep. If its just JS, Turborepo would probably be a better
| choice nowadays.
| nyadesu wrote:
| Would you mind explaining why? I use Nx and it's been good,
| not perfect tho, so at this point I'm very skeptical about
| toolchaining solutions that claim they 'just work'
| bsimpson wrote:
| I haven't used Turborepo, but I have really liked wireit.
| wireit is from the Lit team at Google. They understand both
| Bazel and JS. As I understand, wireit is their attempt to
| make the Bazel niceties JS-native.
| jsw wrote:
| Bazel is a fully reproducible and hermetic build system. A lot of
| painstaking work goes into it producing the exact same artifacts
| build after build. And that provides some interesting properties
| that you can leverage for artifact caching, deployments, and
| CICD.
|
| We very happily runny a polyglot monorepo w/ 5+ languages,
| multiple architectures, with fully reproducible artifacts and
| deployment manifests, all deployed to almost all AWS regions on
| every build. We update tens of thousands of resources in every
| environment for every build. The fact that Bazel is creating
| reproducible artifacts allow us to manage this seamlessly and
| reliably. Clean builds take an hour+, but our GH self-hosted
| runners often complete commit to green build for our devs in less
| than a minute.
|
| The core concept of Bazel is very simple: explicitly declare the
| input you pass to a rule/tool and explicitly declare the output
| it creates. If that can click, you're half way there.
| bmohlenhoff wrote:
| I tried using Bazel a while back but immediately ran into a few
| issues.
|
| The existing codebase I was working with did not lay out its
| dependencies and files in the manner expected by Bazel so dealing
| with dependency/include hell was frustrating.
|
| Then there was a large portion of the project that depended on
| generated code for its interfaces (ie. similar to protobuf but
| slightly different) and trying to dive into the Bazel rules and
| toolchain with no other Bazel experience was not fun. I attempted
| to build off of the protobuf implementation but kept finding
| additional layers to the onion that didn't exactly translate to
| the non protobuf tooling. The project documentation seemed out of
| date in this area (ie. major differences in the rules engine
| between 1.0 and subsequent versions) and I couldn't find many
| examples to look at other than overly simplified toy examples.
|
| All in all a frustrating experience. I could not even get far
| enough along to compile the interfaces for the project.
| adamgordonbell wrote:
| Author here. I wanted to get my head wrapped around when Bazel
| was an excellent build solution, so I interviewed six people with
| a lot of Bazel experience and picked their brains.
|
| This somewhat long article hopes to answer questions about Bazel
| for future people in a similar position to me. If you know a lot
| of Bazel then you might not learn much but if you've vaguely
| heard of it and are not sure when its the tool that should be
| reached for I'm hoping this will help.
| mattboardman wrote:
| Bazel is a great tool, but as mentioned in the article the
| support from Google is rather limited. If bazel ever got to the
| level Terraform is with providers it could really take off.
| Something I'd love to see is a .bazel_mod file where you could
| pull in other bazel workspaces (similar to go.mod) and reference
| packages within those workspaces.
| dimator wrote:
| That's there now:
|
| https://bazel.build/build/bzlmod
| mattboardman wrote:
| TIL. Thanks for the link!
| n0us wrote:
| you can already do that with the WORKSPACE file
| smeagull wrote:
| Haven't yet gotten a single project using Bazel to build on any
| of my machines. I don't think I'd adopt a build system that is so
| frustrating.
___________________________________________________________________
(page generated 2022-09-13 23:00 UTC)