6 ms·

I really can't emphasize enough how much I love using Bazel. The ability to tell a less technical user "just run `bazel run //amazing/server`" regardless of lan

I really can't emphasize enough how much I love using Bazel. The ability to tell a less technical user "just run `bazel run //amazing/server`" regardless of language and know that everything will magically work (toolchain installation, future toolchain upgrades, incremental rebuilds) is really freeing. The actions graph with rules and aspects is quite powerful, so you can do things like add Java nullability checks or Python type checking remarkably easily. Recently I put together a simple build rule that strips external dependencies, archives the rest, and uploads it to a cache. Then we can easily run that archive against a pre-built container (which contains the external dependencies) in our cluster, enabling a very fast ML iteration loop on beefy cluster machines. I've also done a lot of work to enable middle-ground environments, so my users can run Python scripts like they're used to (`python script.py`) while inside of a Bazel environment, which makes it easy for them to develop quickly and then create a BUILD file when they're ready. The major downside I've experienced is that any time you're trying to do something in a less-than-Bazel way (for example relying on binaries built outside of Bazel) things can get really hairy. My containers often need various things from apt repositories, so I had to give up on rules_docker and made my own rules for Podman. I think you need someone who understands aspects and rules before adopting it, or else the sharp edges of Bazel will keep cutting you until you drop it.

jfim 4y ago
> Recently I put together a simple build rule that strips external dependencies, archives the rest, and uploads it to a cache. Then we can easily run that archive against a pre-built container (which contains the external dependencies) in our cluster, enabling a very fast ML iteration loop on beefy cluster machines. Can you tell us more about this? We're using bazel at $day_job and it's about as pleasant as gouging my eyes out with a rusty spoon. Building docker images using bazel takes forever.
- aschleck 4y ago
  Sure! So the overall goal is to prebuild a runfiles tree containing all the external dependencies into a Docker container, and then when the user wants to run something we build a runfiles tree with all the non-external code. Then in the cluster we want to extract the user's runfiles tree on top of the prebuilt runfiles tree, and then execute the user's code. * I have an archive Starlark function that I use for both this and containers. It sets up a folder structure similar to <target>.runfiles with everything symlinked to the actual location, then it tars the whole thing following symlinks. It has a parameter to include files that start with external/ or not. * This archive function is used by my Bazel container rules, so I simply made a runner.py target that depends on every possible external Python dependency and made a Docker image with it. * I then made a Bazel rule that uses the archive function to archive a given executable without external/ and uploads it to a shared location. * At runtime runner.py is given the location as an argument, downloads it, extracts it, and then execv's it.
- gravypod 4y ago
  There's lot of improvements needed in rules_docker. I only really have time for approving PRs. Some OSS devs are working on better abstractions on top of things that should speed stuff up (especially for languages that build static binaries like C++ or Go).
- radvani13 4y ago
  Jim, this is Radhika, and I am the PM for Bazel. I would love to learn more about building docker images using Bazel and your painpoints
lbhdc 4y ago
My impression of bazel has been the same. It makes working with polyglot tech stack a breeze. Do you have an example of the rule that strips and archives your dependencies? Or an example of being able to invoke the python interpreter in a bazel context? I haven't seen anything like that, and want to try it out in my own project.
- aschleck 4y ago
  Unfortunately I can't share code at this time but I just described the archiving in more detail in a sibling comment. The Python interpreter is also quite simple. There's several ways you can do it, but the simplest thing to imagine is if you make a launcher.py script that just invokes Bash as a foreground subprocess. The pstree is kind of funky (bash -> python -> bash), but inside that shell PYTHONPATH will be set approximately correctly. There are reasons to prefer an approach that works with sourcing (eg so you can set PS1), but it's a little harder to describe. You can do some acrobatics to make runfiles (mostly) work, and my recollection is that PATH mostly works but that may require some more work. We do the same thing for Jupyterlab and IPython.
toastal 4y ago
Found it the opposite and it completely put me out of work on NixOS as it starts pulling in a separate JVM and its internal Python was missing libraries and it then pulled unpatchelf'd bins from around the net. The Python-like config language is off-putting too.
throwamon 4y ago
> "just run `bazel run //amazing/server`" regardless of language and know that everything will magically work > The major downside I've experienced is that any time you're trying to do something in a less-than-Bazel way (for example relying on binaries built outside of Bazel) things can get really hairy Sounds like Nix
- ris 4y ago
  As a nixpkgs maintainer I can't tell you how painful Bazel is for packagers. The difficulty of substituting dependencies. Unstable hashes of fetched dependency sources. The infeasibility of building bazel itself fully from source...
  - numbsafari 4y ago
    "substituting dependencies" sounds like an absolute nightmare for an upstream software provider.
    - ris 4y ago
      Ah the upstream "we know everything and we will control everything" provider. Who doesn't maintain stable branches with security backports for their bundled dependencies, includes mystery binary dependencies, doesn't care about anything but the main two architectures, expects users to be fine with having seventeen copies of ffmpeg on their systems, will not let their tool work on a musl-based system...
throwaway894345 4y ago
I tried Bazel once about 5 years ago for a Python project and it definitely wasn't up to task then, and I kind of wrote it off for a while (it was a bad experience). I do like the idea of tools like Bazel and Nix, and I've since moved toward Go and Rust which I think are more of a happy path for Bazel. I wouldn't mind giving it another try, but I'm not eager to bite off a big learning curve (limited spare time, other hobbies, etc). If anyone has any recommendations for gentle introductions to Bazel (ideally for Go), I would appreciate them.
- liuliu 4y ago
  Python support in Bazel now looks more promising with `rules_python`: https://github.com/bazelbuild/rules_python https://github.com/bazelbuild/rules_python `rules_go` to my understanding is great too. Over years, Bazel is not as opinionated as before, mostly because adoptions in different orgs force it to be so.
- deleted 4y ago
  [deleted]
radvani13 4y ago
Hi aschleck, I am the PM for Bazel and love your feedback. Was wondering if you would be open to connecting so I can learn more
- aschleck 4y ago
  Sure! My email is in my profile, not sure how to contact you.
kaba0 4y ago
Do you happen to have experience with Gradle? It is not used at multi-language projects too often, but I would be interested in your comparison of the two.

jfim 4y ago

> Recently I put together a simple build rule that strips external dependencies, archives the rest, and uploads it to a cache. Then we can easily run that archive against a pre-built container (which contains the external dependencies) in our cluster, enabling a very fast ML iteration loop on beefy cluster machines. Can you tell us more about this? We're using bazel at $day_job and it's about as pleasant as gouging my eyes out with a rusty spoon. Building docker images using bazel takes forever.

aschleck 4y ago
Sure! So the overall goal is to prebuild a runfiles tree containing all the external dependencies into a Docker container, and then when the user wants to run something we build a runfiles tree with all the non-external code. Then in the cluster we want to extract the user's runfiles tree on top of the prebuilt runfiles tree, and then execute the user's code. * I have an archive Starlark function that I use for both this and containers. It sets up a folder structure similar to <target>.runfiles with everything symlinked to the actual location, then it tars the whole thing following symlinks. It has a parameter to include files that start with external/ or not. * This archive function is used by my Bazel container rules, so I simply made a runner.py target that depends on every possible external Python dependency and made a Docker image with it. * I then made a Bazel rule that uses the archive function to archive a given executable without external/ and uploads it to a shared location. * At runtime runner.py is given the location as an argument, downloads it, extracts it, and then execv's it.
gravypod 4y ago
There's lot of improvements needed in rules_docker. I only really have time for approving PRs. Some OSS devs are working on better abstractions on top of things that should speed stuff up (especially for languages that build static binaries like C++ or Go).
radvani13 4y ago
Jim, this is Radhika, and I am the PM for Bazel. I would love to learn more about building docker images using Bazel and your painpoints

lbhdc 4y ago

My impression of bazel has been the same. It makes working with polyglot tech stack a breeze. Do you have an example of the rule that strips and archives your dependencies? Or an example of being able to invoke the python interpreter in a bazel context? I haven't seen anything like that, and want to try it out in my own project.

aschleck 4y ago
Unfortunately I can't share code at this time but I just described the archiving in more detail in a sibling comment. The Python interpreter is also quite simple. There's several ways you can do it, but the simplest thing to imagine is if you make a launcher.py script that just invokes Bash as a foreground subprocess. The pstree is kind of funky (bash -> python -> bash), but inside that shell PYTHONPATH will be set approximately correctly. There are reasons to prefer an approach that works with sourcing (eg so you can set PS1), but it's a little harder to describe. You can do some acrobatics to make runfiles (mostly) work, and my recollection is that PATH mostly works but that may require some more work. We do the same thing for Jupyterlab and IPython.

toastal 4y ago

Found it the opposite and it completely put me out of work on NixOS as it starts pulling in a separate JVM and its internal Python was missing libraries and it then pulled unpatchelf'd bins from around the net. The Python-like config language is off-putting too.

throwamon 4y ago

> "just run `bazel run //amazing/server`" regardless of language and know that everything will magically work > The major downside I've experienced is that any time you're trying to do something in a less-than-Bazel way (for example relying on binaries built outside of Bazel) things can get really hairy Sounds like Nix

ris 4y ago
As a nixpkgs maintainer I can't tell you how painful Bazel is for packagers. The difficulty of substituting dependencies. Unstable hashes of fetched dependency sources. The infeasibility of building bazel itself fully from source...
- numbsafari 4y ago
  "substituting dependencies" sounds like an absolute nightmare for an upstream software provider.
  - ris 4y ago
    Ah the upstream "we know everything and we will control everything" provider. Who doesn't maintain stable branches with security backports for their bundled dependencies, includes mystery binary dependencies, doesn't care about anything but the main two architectures, expects users to be fine with having seventeen copies of ffmpeg on their systems, will not let their tool work on a musl-based system...

throwaway894345 4y ago

I tried Bazel once about 5 years ago for a Python project and it definitely wasn't up to task then, and I kind of wrote it off for a while (it was a bad experience). I do like the idea of tools like Bazel and Nix, and I've since moved toward Go and Rust which I think are more of a happy path for Bazel. I wouldn't mind giving it another try, but I'm not eager to bite off a big learning curve (limited spare time, other hobbies, etc). If anyone has any recommendations for gentle introductions to Bazel (ideally for Go), I would appreciate them.

liuliu 4y ago
Python support in Bazel now looks more promising with `rules_python`: https://github.com/bazelbuild/rules_python https://github.com/bazelbuild/rules_python `rules_go` to my understanding is great too. Over years, Bazel is not as opinionated as before, mostly because adoptions in different orgs force it to be so.
deleted 4y ago
[deleted]

radvani13 4y ago

Hi aschleck, I am the PM for Bazel and love your feedback. Was wondering if you would be open to connecting so I can learn more

aschleck 4y ago
Sure! My email is in my profile, not sure how to contact you.

kaba0 4y ago

Do you happen to have experience with Gradle? It is not used at multi-language projects too often, but I would be interested in your comparison of the two.