7 ms·

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.

by jnxx 6y ago

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.
- jnxx 6y ago
  > It's designed first and foremost to work with vendored dependencies in a monorepo So how is that suitable for distributed open source projects? I understand this is how Google works, but open source?

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.

by 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.

jnxx 6y ago
> It's designed first and foremost to work with vendored dependencies in a monorepo So how is that suitable for distributed open source projects? I understand this is how Google works, but open source?