|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Abseil Py||2,039||2,037||521||a day ago||38||June 01, 2022||16||apache-2.0||Python|
|Abseil Common Libraries (Python)|
|Zetasql||1,955||1||8 days ago||21||August 16, 2022||80||apache-2.0||C++|
|ZetaSQL - Analyzer Framework for SQL|
|Bazelisk||1,393||13||4 hours ago||15||June 15, 2022||88||apache-2.0||Go|
|A user-friendly launcher for Bazel.|
|Asylo||911||a year ago||17||apache-2.0||C++|
|An open and flexible framework for developing enclave applications|
|Rules_rust||475||3 hours ago||256||apache-2.0||Starlark|
|Rust rules for Bazel|
|Rules_kotlin||298||16 days ago||179||apache-2.0||Starlark|
|Bazel rules for Kotlin|
|Rules_proto||134||21 days ago||26||apache-2.0||Starlark|
|Protocol buffer rules for Bazel|
|Pybind11_bazel||67||a month ago||16||other||Starlark|
|Bazel wrapper around the pybind11 repository|
|Hrepl||42||2 years ago||13||apache-2.0||Haskell|
|Interactive development for Bazel/Haskell rules|
|Bazel Stack Vscode||38||7 months ago||17||other||TypeScript|
|VSCode Extension for Bazel|
A user-friendly launcher for Bazel.
Bazelisk is a wrapper for Bazel written in Go. It automatically picks a good version of Bazel given your current working directory, downloads it from the official server (if required) and then transparently passes through all command-line arguments to the real Bazel binary. You can call it just like you would call Bazel.
brew install bazelisk.
choco install bazelisk.
Each adds bazelisk to the
PATH as both
On Linux: You can download Bazelisk binary on our Releases page and add it to your
PATH manually, which also works on macOS and Windows.
Bazelisk is also published to npm.
Frontend developers may want to install it with
npm install -g @bazel/bazelisk.
You will notice that it serves an analogous function for Bazel as the
nvmutility which manages your version of Node.js.
Some ideas how to use it:
bazelbinary in your
PATH(e.g. copy it to
/usr/local/bin/bazel). Never worry about upgrading Bazel to the latest version again.
./bazelisk build //my:software. That way, even someone who has never used Bazel or doesn't have it installed can build your software.
.bazelversionfile to your repository. This will tell Bazelisk to use the exact version specified in the file when running in your workspace. The fact that it's versioned inside your repository will then allow for atomic upgrades of Bazel including all necessary changes. If you install Bazelisk as
bazelon your CI machines, too, you can even test Bazel upgrades via a normal presubmit / pull request. It will also ensure that users will not try to build your project with an incompatible version of Bazel, which is often a cause for frustration and failing builds. (But see the note below about ensuring your developers install Bazelisk.)
Before Bazelisk was rewritten in Go, it was a Python script. This still works and has the advantage that you can run it on any platform that has a Python interpreter, but is currently unmaintained and it doesn't support as many features. The documentation below describes the newer Go version only.
It uses a simple algorithm:
USE_BAZEL_VERSIONis set, it will use the version specified in the value.
.bazeliskrcfile exists in the workspace root and contains the
USE_BAZEL_VERSIONvariable, this version will be used.
.bazelversionfile exists in the current directory or recursively any parent directory, it will read the file and use the version specified in it.
USE_BAZEL_FALLBACK_VERSIONis set to one of the following formats:
error:, it will report an error and version detection will fail.
warn:, it will report a warning and use the version specified after the prefix.
silent:, it will use the version specified after the prefix.
A version can optionally be prefixed with a fork name.
The fork and version should be separated by slash:
Please see the next section for how to work with forks.
Bazelisk currently understands the following formats for version labels:
latestmeans the latest stable (LTS) version of Bazel as released on GitHub. Previous releases can be specified via
0.17.2means that exact version of Bazel. It can also be a release candidate version like
0.20.0rc3, or a rolling release version like
4.xthat returns the latest release from the LTS series started by Bazel 4.0.0.
Additionally, a few special version names are supported for our official releases only (these formats do not work when using a fork):
last_greenrefers to the Bazel binary that was built at the most recent commit that passed Bazel CI. Ideally this binary should be very close to Bazel-at-head.
last_downstream_greenpoints to the most recent Bazel binary that builds and tests all downstream projects successfully.
last_rcpoints to the most recent release candidate. If there is no active release candidate, Bazelisk uses the latest Bazel release instead.
rollingrefers to the latest rolling release (even if there is a newer LTS release).
By default Bazelisk retrieves Bazel releases, release candidates and binaries built at green commits from Google Cloud Storage.
As mentioned in the previous section, the
<FORK>/<VERSION> version format allows you to use your own Bazel fork hosted on GitHub:
If you want to create a fork with your own releases, you have to follow the naming conventions that we use in
bazelbuild/bazel for the binary file names.
The URL format looks like
You can also override the URL by setting the environment variable
$BAZELISK_BASE_URL. Bazelisk will then append
/<VERSION>/<FILENAME> to the base URL instead of using the official release server. Bazelisk will read file
~/.netrc for credentials for Basic authentication.
Bazel installers typically provide Bazel's shell wrapper script as the
bazel on the PATH.
When installed this way, Bazel checks the
.bazelversion file itself, but the failure when it mismatches with the actual version of Bazel can be quite confusing to developers.
You may find yourself having to explain the difference between Bazel and Bazelisk (especially when you upgrade the pinned version).
To avoid this, you can add a check in your
Since Bazelisk is careful to avoid calling itself in a loop, it always calls the wrapper with the environment variable
BAZELISK_SKIP_WRAPPER set to `true'.
You can check for the presence of that variable, and when not found, report a useful error to your users about how to install Bazelisk.
Note that if users directly downloaded a Bazel binary and put it in their PATH, rather than running
an installer, then
.bazelversion are not checked. You could call the
versions.check starlark module from the beginning of your WORKSPACE to
require users update their bazel.
The Go version of Bazelisk offers two new flags.
--strict expands to the set of incompatible flags which may be enabled for the given version of Bazel.
bazelisk --strict build //...
--migrate will run Bazel multiple times to help you identify compatibility issues.
If the code fails with
--strict, the flag
--migrate will run Bazel with each one of the flag separately, and print a report at the end.
This will show you which flags can safely enabled, and which flags require a migration.
You can set
BAZELISK_INCOMPATIBLE_FLAGS to set a list of incompatible flags (separated by
,) to be tested, otherwise Bazelisk tests all flags starting with
You can set
BAZELISK_GITHUB_TOKEN to set a GitHub access token to use for API requests to avoid rate limiting when on shared networks.
You can set
BAZELISK_SHUTDOWN to run
shutdown between builds when migrating if you suspect this affects your results.
You can set
BAZELISK_CLEAN to run
clean --expunge between builds when migrating if you suspect this affects your results.
tools/bazel exists in your workspace root and is executable, Bazelisk will run this file, instead of the Bazel version it downloaded.
It will set the environment variable
BAZEL_REAL to the path of the downloaded Bazel binary.
This can be useful, if you have a wrapper script that e.g. ensures that environment variables are set to known good values.
This behavior can be disabled by setting the environment variable
BAZELISK_SKIP_WRAPPER to any value (except the empty string) before launching Bazelisk.
You can control the user agent that Bazelisk sends in all HTTP requests by setting
BAZELISK_USER_AGENT to the desired value.
The Go version supports a
.bazeliskrc file in the root directory of a workspace and the user home directory. This file allows users to set environment variables persistently.
Example file content:
The following variables can be set:
Configuration variables are evaluated with precedence order. The preferred values are derived in order from highest to lowest precedence as follows:
For ease of use, the Python version of Bazelisk is written to work with Python 2.7 and 3.x and only uses modules provided by the standard library.
The Go version can be compiled to run natively on Linux, macOS and Windows.
You need at least Go 1.11 to build Bazelisk, otherwise you'll run into errors like
To install the Go version, type:
go get github.com/bazelbuild/bazelisk
With Go 1.17 or later, the recommended way to install it is:
go install github.com/bazelbuild/[email protected]
To add it to your PATH:
export PATH=$PATH:$(go env GOPATH)/bin
For more information, you may read about the
GOPATH environment variable.
It creates a directory called "bazelisk" inside your user cache directory and will store them there. Feel free to delete this directory at any time, as it can be regenerated automatically when required.