[nisa]

I'm still not sure if I should go the bazel route... recently found a long good explanation why anki switched away from bazel: https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4...

I'd love to have cachable builds but I wonder how much effort it takes to maintain such a setup - especially in a small team very far away from silicon valley or google were nobody saw bazel before. Would be a perfect fit for my former company but even there I couldn't convince my colleagues - they build a monster using maven which would be more elegant in bazel but maven integration worked different than the maven algorithm at least 2 years ago...so my PoC turned into reading source code of dependency resolution algorithm in the used scala tool coursier... in the end I had to give up after patching maven issues in several projects we build upon - something nobody is willing to do I guess - to be fair I tried to incorporate Alfresco ECM which is quite an enterprise Java monster on it's own.

Also I couldn't find a good approach to use multiple git repositories almost all tutorials use a monorepo.

[aseipp]

Was your project built in multiple languages and tied together using Maven? Or was it just JDK languages/Java?

Tools like Bazel or Nix or <whatever you enjoy> are incredible for many reasons but they are, to a first approximation, very, very high-effort and complex tools that require care. It's like a racing car. You need an engineer on hand to keep the car running, and someone to drive it too. Maybe you're both of those people, but only a driver isn't enough.

They also suffer from another problem which is that most people don't care as much as you or I do. :) So to make it a slam dunk, you have to make a pretty clear case that it's not "just" 2x better, but actually 10x better. And it's actually even harder than that: it can't just be 10x better in practice, it has to appear 10x better at a glance. Like, at the window shopping phase, it needs to catch their eye. That's difficult to nail and basically impossible to do perfectly.

Personally? I'm all-in on "whole sale" build tools like this that hit many nails with one hammer. They solve a tremendous amount of issues. But they aren't always good and I can really see why they can fail to gain traction for many teams: they simply aren't necessary for them, even if they're really a lot better in many ways. I get it.

[nisa]

> Was your project built in multiple languages and tied together using Maven? Or was it just JDK languages/Java?

Exactly that - for one it was a plugin for Alfresco ECM that disobeyed every Alfresco SDK rule :), then a custom Angular frontend that needs to be build according to the plugin - furthermore the business was of that kind that every customer had a specialized build with customization - Bazel would have solved that in a very neat way - including overriding a few source files for a specific customer.

We tried to build then docker images with maven which was just a shitshow considering our problems - however I'm not there anymore but I'd like to have the exact setup that you describe - the big hammer to don't have to deal with all the stupid things - especially as my background is sysadmin and every problem I don't have to solve anymore is good for me :)

[rgoulter]

> Tools like Bazel or Nix or ...

I find it interesting that Bazel and Nix don't seem to complement each other as much as I'd think given that they're both 'high effort, high reward tools which deal with hermetic building'.

They certainly both suffer from issues related to upstream packages doing their own thing.

> They also suffer from another problem which is that most people don't care as much as you or I do. :) ...

I use Nix. I haven't use Bazel.

I think Nix is wonderful for enthusiasts. It takes some time to learn. However, Nix is excellent at dealing with packages. And developers often do things which involve packages. -- e.g. Nix is good for declaring a shell with programs that can be made available.

[perrygeo]

> They certainly both suffer from issues related to upstream packages doing their own thing.

Having used both Bazel and Nix, I agree they suffer here but with a slightly different take: They suffer because they must reinvent the wheel and provide a new API to mimic the upstream package managers. They're in a constant race to keep pace with best practices outside of their community - and patch their APIs accordingly which become "dirty mirrors", only partially reflecting the intent and functionality of upstream tooling.

But that's kind of the point - they apparently need to take over and constrain the system to fully understand the dependency tree.

I wish there was a Bazel/Nix/Guix build tool that had some barrier between the dependency tree and the developer tools that one uses daily. When I'm building the system as a whole, I don't want to think about cargo vs npm. But when I'm writing code for a given component, the native tooling is the correct abstraction. Is it even theoretically possible to resolve those two ideas without introducing another glue language?

[nisa]

There is https://github.com/tweag/rules_nixpkgs which is something I wanted to look into.

[carlmr]

Bazel is definitely worth it if you have a large enough repo. But if you have such a large repo you can and should have a team that's dedicated to CI, builds, etc.

If you have a small team and repo it's probably not worth the effort.

[ranting-moth]

In my experience you need a Bazel expert on the team.

When everything works it's amazing. When it doesn't or additional work is required the hope your local expert is online and willing to sort it out.

[maccard]

This is true for any language ecosystem or build tool, whether it's bazel, maven, unrealbuildtool, Jenkins, cmake, gradle etc.

[oblio]

The thing is, if you hire 20 Java devs, at least one of them will already be an advanced Maven user. Same for Python and poetry/pipenv, Javascript/npm, etc.

Bazel is kind of to the side everywhere.

[Groxx]

Just speaking to multiple git repositories: could you use submodules for a conglomerated-monorepo?

Otherwise: you can pull in repos as bazel-file-containing additions. I forget the details, but I believe it's something like https://bazel.build/extending/repo . The troubleshooting-while-developing experience is not great though imo, I'd try submodules first.

[nisa]

Thanks - repository_rule looks good. So it's either git submodules to maintain updates or checksums / commits in repository_rule - I probably need to just play around with both approaches and choose the one that annoys me the least :)

[dbaupp]

We’ve had a good experience using Pants 2 (https://www.pantsbuild.org/) and its dependency inference (https://blog.pantsbuild.org/why-dependency-inference/) for Python. Although we are in a monorepo, rather than a “multi-repo”.

[jitl]

It's cool that Pants has enough community to evolve beyond being a Twitter-led project. It seems Twitter itself migrated from Pants to Bazel, and no longer works on Pants: https://groups.google.com/g/pants-devel/c/PHVIbVDLhx8/m/LpSK...

I find it hard to buy into one of these "mega build system" ecosystems because there are so many competing tools that descend from Blaze: Bazel, Pants, Buck, Buck2, etc. The migration path to these systems takes substantial effort, so I wouldn't want to bet on the wrong one and have to do it all again a few years later. I'm content to wait patiently for Bazel or Buck2 to clearly win before I invest.

[dbaupp]

I have the sense that migrating to any hermetic, cacheable build system will be more effort than migrating from one to another: once a project is “safe” to have everything run in sandboxes, the mechanisms for setting up those sandboxes is less important. For example, once one system has accurate dependency information, that can be used as a base for setting up the second system (and presumably this info can be exported for machine-assisted migration).

Of course, the details of each system differ enough that I imagine it’s not trivial.

[jen20]

Do you know what the current maintenance story for Pants is following Twitter's move to Bazel?

[dbaupp]

It seems to be quite active, with regular new releases. I’m lead to believe that https://www.toolchain.com/ is the main sponsor, but there are maintainers from other companies too. I do not know the details, though.

[jeffreygoesto]

Maybe check out justbuild [0], the main author used to be a bazel dev and wanted to combine it's strengths with the possibility of multi repos and more possibilities to interact with the dependency tree. Quite interesting and very responsive team.

[0] https://github.com/just-buildsystem/justbuild

[hobofan]

Aaarg, I hate to always be the person that points out "naming issues", but there is already a pretty popular command runner with the name just: https://github.com/casey/just

[jvolkman]

I suppose that's the risk of picking a common word as your project name.

[eklitzke]

I'm not going to try to convince you to use Bazel. I think it's great, but ultimately choosing one build system or another is a big decision that involves weighing a lot of different factors, including what your coworkers are amenable to and have experience with. However I don't think Bazel is that difficult to get started with.

The Bazel docs are admittedly a bit challenging, but the easiest way to learn things when you're first getting started is to just look at other projects using Bazel and see how they do things.

Using multiple git repositories is easy, you just use the git_repository() rule which has been in Bazel since pretty much forever. Nowadays you can also use bzlmod (introduced in bazel 5.x) which is a slightly different approach to this problem. There are a bunch of rules in https://github.com/bazelbuild/bazel-central-registry which you can look at to see how to write your own bzlmod registries.

[nisa]

bzlmod looks amazing! Thank you! I don't need to be convinced but I need to sell it to my team and I must be able to solve our problems in it - imho getting it working solves 90% of annoying problems in this whole ci/cd/container mess and that's why I'd like to push for it.

[hobofan]

The BCR also has a web UI at https://registry.bazel.build

[actionfromafar]

I've been meaning to try out XMake [0]. It has caching and distributed build and seems much easier to understand than Bazel.

0: https://xmake.io/#/getting_started