6 ms·

I've used bazel pretty extensively and I have to say it's not fully baked unless you're using it the way Google does internally (vendor all dependencies) and yo

I've used bazel pretty extensively and I have to say it's not fully baked unless you're using it the way Google does internally (vendor all dependencies) and you're using a language Google does internally. Additionally, it wants to take over your entire build process end to end. Get used to prefixing every shell command with `bazel run` or `bazel build` because everything goes into a little sandbox and bazel likes to be in the middle of everything. These tradeoffs make sense at Google scale (the goal of bazel is to have very repeatable builds), but in my opinion it's a huge drag with not much benefit for smaller shops (to be clear, "Oh you only have 200 developers?" Still a small shop by these standards)

tonetheman 8y ago
I am a minority I feel but everywhere I have ever worked I have always pushed to keep your dependencies close. There was never a way to reproduce a build without doing so. I know other smart people want badly to trust in outside sources ... but I am old and jaded. And never skipped a build because npm was down... or before that if I could get a jar from a remote source ... and so on.
- lstamour 8y ago
  Bazel encourages you to list geographically diverse sources to download from for workspace setup. That said, you could run a local proxy with something like Squid or Varnish, turn on caching in a remote build server, or set up a mono-repo and never use npm (as Google does), each has advantages and tradeoffs... you could also archive and backup your Bazel folders to hermetically reproduce workspaces and builds if patching is necessary, though you’d have to also archive a copy of your host or build environment if you’re paranoid about host tools or configurations changing.
- habitue 8y ago
  Vendoring is totally a thing you can do, but keeping them up to date with upstream (and keeping your bazel BUILD files current) is a full time job. You have to hire someone to do that work, it's not completely automatable.
  - vageli 8y ago
    Non-security upgrades probably _shouldn't_ be automated.
    - habitue 8y ago
      Absolutely agree. But I meant maintaining BUILD files for code you didn't write can be very time consuming. Even a security-only update can include new source files that you now have to tell Bazel about. It's real work
xyzzy_plugh 8y ago
> unless you're using a language Google does internally. If only. Go support is pretty horrific and painful.
krona 8y ago
Bazel, from the outset, wasn't designed for open source projects that tend to have dependencies with incompatible build systems. It isn't flexible enough.
mark_l_watson 8y ago
Thank you for those comments. For my own projects at home I mostly use Haskell, Python, and Java, but sometimes also Typescript, SBCL Common Lisp, Racket, Chez Scheme, and Scala. I was imagining getting set up to build everything with Bazel after reading the article but your comments are on point and made me reconsider. I used to vender locally Ruby, Merb, Rails, and most Java libraries I used - but I stopped doing that about ten years ago.

tonetheman 8y ago

I am a minority I feel but everywhere I have ever worked I have always pushed to keep your dependencies close. There was never a way to reproduce a build without doing so. I know other smart people want badly to trust in outside sources ... but I am old and jaded. And never skipped a build because npm was down... or before that if I could get a jar from a remote source ... and so on.

lstamour 8y ago
Bazel encourages you to list geographically diverse sources to download from for workspace setup. That said, you could run a local proxy with something like Squid or Varnish, turn on caching in a remote build server, or set up a mono-repo and never use npm (as Google does), each has advantages and tradeoffs... you could also archive and backup your Bazel folders to hermetically reproduce workspaces and builds if patching is necessary, though you’d have to also archive a copy of your host or build environment if you’re paranoid about host tools or configurations changing.
habitue 8y ago
Vendoring is totally a thing you can do, but keeping them up to date with upstream (and keeping your bazel BUILD files current) is a full time job. You have to hire someone to do that work, it's not completely automatable.
- vageli 8y ago
  Non-security upgrades probably _shouldn't_ be automated.
  - habitue 8y ago
    Absolutely agree. But I meant maintaining BUILD files for code you didn't write can be very time consuming. Even a security-only update can include new source files that you now have to tell Bazel about. It's real work

xyzzy_plugh 8y ago

> unless you're using a language Google does internally. If only. Go support is pretty horrific and painful.

krona 8y ago

Bazel, from the outset, wasn't designed for open source projects that tend to have dependencies with incompatible build systems. It isn't flexible enough.

mark_l_watson 8y ago

Thank you for those comments. For my own projects at home I mostly use Haskell, Python, and Java, but sometimes also Typescript, SBCL Common Lisp, Racket, Chez Scheme, and Scala. I was imagining getting set up to build everything with Bazel after reading the article but your comments are on point and made me reconsider. I used to vender locally Ruby, Merb, Rails, and most Java libraries I used - but I stopped doing that about ten years ago.