3 ms·
Each dependency appears as a "repository" so as a bazel target it will look like "@<thing>//some/target:file". Everything refers to a dep by it's workspace/repo
by gravypod 6y ago
Each dependency appears as a "repository" so as a bazel target it will look like "@<thing>//some/target:file". Everything refers to a dep by it's workspace/repository name and exports a `repository.bzl` or `workspace.bzl` file that your WORKSPACE file `load()`s and calls a function in.
This is pretty standardized and "recommended" by bazel-federation: https://github.com/bazelbuild/bazel-federation https://github.com/bazelbuild/bazel-federation
A good example of how this becomes a massive mess: https://github.com/bazelbuild/rules_docker/blob/master/repositories/repositories.bzl https://github.com/bazelbuild/rules_docker/blob/master/repos...
- jeffbee 6y agoIt does seem a bit high touch, but don't I also have the alternative of just cloning third party code into my repo and bazelizing it myself? I've certainly seen that done, and it's what Google does internally as well.
- gravypod 6y agoIt's possible and what I've done quite a bit when using bazel but it makes code sharing very difficult. I think the internal desire, from google, is likely between tensorflow and cloud wanting to ship code easily to the OSS world. One of the reasons PyTorch is taking off is because people can build it easily!