bazel-skylib
dbx_build_tools
Our great sponsors
| bazel-skylib | dbx_build_tools | |
|---|---|---|
| 1 | 1 | |
| 364 | 202 | |
| 3.3% | 1.0% | |
| 6.9 | 7.8 | |
| 3 days ago | 9 months ago | |
| Starlark | Go | |
| Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
bazel-skylib
-
master.zip unavailable?
Error downloading [https://github.com/bazelbuild/bazel-skylib/archive/master.zip]
dbx_build_tools
-
Reflecting on the Shake Build System
> hermetic == sandbox which only contains declared deps
Yes, exactly. It also can include other deps like networking. A perfect hermetic build will (for most of the build process) not have access to the network.
> I assume bazel implements this via containers?
Sort of. Bazel's code predates "containers" by ~6 years. Bazel is the build system used at Google (sprinkle on a large amount of asterisks here).
> Also, IMO, this only provides a false sense of safety unless you archive absolutely everything that's inside the sandbox.
Yes, that is what a Bazel monorepo does. You can also include your language's runtime and standard library as part of the build process. See Dropbox's repo for more details on how they do this with Python: https://github.com/dropbox/dbx_build_tools
Some more details about what Google does are available here: https://opensource.google/docs/thirdparty/#
Essentially, everything is built from source (more asterisks here). Since everything is built from source using Bazel you can guarantee that at a certain view of the source repository you can build a reproducible copy of all software in the repo (more asterisks).
One other nice property is you can guarantee that all software in the repo is using a compatible version of each dep: https://opensource.google/docs/thirdparty/oneversion/
The downside is that if you want to upgrade a library that has a breaking change this requires you update a lot of code. The upside is that doing that isn't actually that hard with the tooling available and you can guarantee that you can link together any two libraries in the repo (more asterisks) and have the build succeed without any dep version conflicts. Since you can do this some langauges with runtimes (like JVM language) can see massive speed boosts because they only need to compile changed libraries and can run a `java -cp ... your.jar` to load up deps. You can check out rules_docker for some examples of how this can be used.
What are some alternatives?
rules_nixpkgs - Rules for importing Nixpkgs packages into Bazel.
abseil-py - Abseil Common Libraries (Python)
bazel-coverage-report-renderer - Haskell rules for Bazel.
rules_python - Bazel Python Rules
rules_nodejs - NodeJS toolchain for Bazel.
nixpkgs - Nix Packages collection & NixOS
rules_graalvm - Build GraalVM native binaries with Bazel
buildtools - A bazel BUILD file formatter and editor
sml_rules - Bazel SML rules provide the necessary rules to build and test SML (Standard ML) applications using Bazel.
eidos-audition - Collection of auditory models.
rules_scala - Scala rules for Bazel