7 ms·

I'm glad to see this. What people first and foremost forget is Bazel is a package manager/overlay in itself (and a very good one too), which allows for very com

by steeve 6y ago

I'm glad to see this. What people first and foremost forget is Bazel is a package manager/overlay in itself (and a very good one too), which allows for very complex (and yet safe and reproducible) builds. The learning curve is steep though, but the payoff is so worth it.

TotempaaltJ 6y ago
I just started using Bazel this weekend for a personal (Rust) project. I understood the concepts which convinced me it was something I wanted to use. The documentation and tutorials definitely make the learning curve steeper than I think it needs to be. It works so great though, now that I've managed to set it up.
- JamesSwift 6y ago
  Agreed. I flirted with it a couple times in the past and just couldn't get understand through the docs. This last time I ended up binging the bazelcon videos and things mostly clicked. The main thing to understand is the WORKSPACE/BUILD distinction and then you can mostly get there I think.
  - laurentlb 6y ago
    Thanks for the feedback! Do you have more specific feedback about the documentation? We can definitely make clearer the distinction between BUILD and WORKSPACE. Are there other concepts to clarify, or specific pages we should revamp? Thanks!
    - JamesSwift 6y ago
      I don't have any specific example off the top unfortunately, and some of my confusion was likely because I was trying to pick it up along the road of Bazel maturity so things were changing. When I say BUILD vs WORKSPACE distinction, I actually mean it was tough as an outsider who hasn't used a blaze-like system (or Cmake for that matter) to understand what the guardrails in bazel were and how the WORKSPACE provides certain guarantees to the rest of the system. So, it is a conceptual thing that once I understood that role, things clicked.
jnxx 6y ago
My impression is that it can end up with your requirements spread over half of the Internet with very little control which code runs during your build.
- wwright 6y ago
  Disable outgoing network in CI and vendor everything? For many modern tools such as Python, JS, and Rust, you’d have to do this if you want to “control” everything anyways
  - fock 6y ago
    resulting in things like the official tensorflow-distribution needing patching at 2 parts iirc to compile on new glibcs, because tensorflow and some network-dependency both vendor an outdated library overwriting a new glibc-function (some logging thing...). It works, until you want to fix some thing. Good times.
- steeve 6y ago
  That's up to you. Bazel can fetch and build core from wherever: local or remote. Also, when fetching from git, it will high encourage you to use commits instead of tags, or when downloading archives from http, use a sha256. Actually it will nag you until you do.
- klodolph 6y ago
  Depends on how you do it. It's designed first and foremost to work with vendored dependencies in a monorepo, and the external repository support is newer. Bazel won't pull in transitive dependencies unless you ask it to in the WORKSPACE file, which means that you can use a private mirror for all your dependencies if you like, which is fairly easy in practice (I do it for personal projects). The experience will vary depending on your preferences and the languages you use. With Go + Bazel, my experience is that the Bazel version will have fewer dependencies than the equivalent "go mod" version, because "go mod" will pull in dependencies more coarsely and Bazel has more fine-grained control. Go mod will pull in dependencies for the entire repo that you depend on, but with Bazel, you only need dependencies for the individual subpackages. As a specific example... suppose you use github.com/jackc/pgx. With "go mod" you end up with "github.com/sirupsen/logrus" in your transitive dependencies, but with Bazel you don't, unless you use the part of pgx that requires logrus. You can also end up with "half the internet" in your dependencies pretty easily, but I think these days that is just the price of including random libraries in your project. As far as I can tell, the approach to avoid depending on half the internet is to be very conservative about your dependencies, but that is true regardless of the system you use to manage them. Just to pick on the JavaScript ecosystem, if you start a new JavaScript project and pull in TypeScript, Rollup, and Terser, you'll end up with a very SMALL lock file because each of these libraries have a very small number of carefully chosen dependencies.

by steeve 6y ago

TotempaaltJ 6y ago

I just started using Bazel this weekend for a personal (Rust) project. I understood the concepts which convinced me it was something I wanted to use. The documentation and tutorials definitely make the learning curve steeper than I think it needs to be. It works so great though, now that I've managed to set it up.

JamesSwift 6y ago
Agreed. I flirted with it a couple times in the past and just couldn't get understand through the docs. This last time I ended up binging the bazelcon videos and things mostly clicked. The main thing to understand is the WORKSPACE/BUILD distinction and then you can mostly get there I think.
- laurentlb 6y ago
  Thanks for the feedback! Do you have more specific feedback about the documentation? We can definitely make clearer the distinction between BUILD and WORKSPACE. Are there other concepts to clarify, or specific pages we should revamp? Thanks!
  - JamesSwift 6y ago
    I don't have any specific example off the top unfortunately, and some of my confusion was likely because I was trying to pick it up along the road of Bazel maturity so things were changing. When I say BUILD vs WORKSPACE distinction, I actually mean it was tough as an outsider who hasn't used a blaze-like system (or Cmake for that matter) to understand what the guardrails in bazel were and how the WORKSPACE provides certain guarantees to the rest of the system. So, it is a conceptual thing that once I understood that role, things clicked.

jnxx 6y ago

My impression is that it can end up with your requirements spread over half of the Internet with very little control which code runs during your build.

wwright 6y ago
Disable outgoing network in CI and vendor everything? For many modern tools such as Python, JS, and Rust, you’d have to do this if you want to “control” everything anyways
- fock 6y ago
  resulting in things like the official tensorflow-distribution needing patching at 2 parts iirc to compile on new glibcs, because tensorflow and some network-dependency both vendor an outdated library overwriting a new glibc-function (some logging thing...). It works, until you want to fix some thing. Good times.
steeve 6y ago
That's up to you. Bazel can fetch and build core from wherever: local or remote. Also, when fetching from git, it will high encourage you to use commits instead of tags, or when downloading archives from http, use a sha256. Actually it will nag you until you do.
klodolph 6y ago
Depends on how you do it. It's designed first and foremost to work with vendored dependencies in a monorepo, and the external repository support is newer. Bazel won't pull in transitive dependencies unless you ask it to in the WORKSPACE file, which means that you can use a private mirror for all your dependencies if you like, which is fairly easy in practice (I do it for personal projects). The experience will vary depending on your preferences and the languages you use. With Go + Bazel, my experience is that the Bazel version will have fewer dependencies than the equivalent "go mod" version, because "go mod" will pull in dependencies more coarsely and Bazel has more fine-grained control. Go mod will pull in dependencies for the entire repo that you depend on, but with Bazel, you only need dependencies for the individual subpackages. As a specific example... suppose you use github.com/jackc/pgx. With "go mod" you end up with "github.com/sirupsen/logrus" in your transitive dependencies, but with Bazel you don't, unless you use the part of pgx that requires logrus. You can also end up with "half the internet" in your dependencies pretty easily, but I think these days that is just the price of including random libraries in your project. As far as I can tell, the approach to avoid depending on half the internet is to be very conservative about your dependencies, but that is true regardless of the system you use to manage them. Just to pick on the JavaScript ecosystem, if you start a new JavaScript project and pull in TypeScript, Rollup, and Terser, you'll end up with a very SMALL lock file because each of these libraries have a very small number of carefully chosen dependencies.