Please keep the Python version maintained

[jbms]

This isn't in reference to any specific issue --- the Python version currently works perfectly fine, and perhaps it will continue working indefinitely.

I just wanted to add my encouragement generally to keep the Python version around. The Python version very nicely solves the bootstrapping problem: I can include a copy of bazelisk.py in my repository, and in the documentation just tell users to invoke:

python bazelisk.py ...

in order to execute the build without any additional steps.

On Linux and macOS at least some version of Python is sure to already be available, and on Windows it is also likely to already be available (especially if the project itself requires it). The only downside is that on macOS, Python doesn't have access to a certificate store by default, so the user has to perform an additional step if not already set up.

Since I have my WORKSPACE already set up to download all dependencies, this keeps the installation procedure quite simple --- the user doesn't have to install any dependencies manually, which is very convenient --- users may otherwise be put off by having to install Bazel manually.

In contrast the Go version basically doesn't solve my use case at all: I would have to tell users to manually install it. But that isn't really any easier than just installing Bazel. It does still provide some benefit in managing bazel versions, but the overall convenience is much lower.

What was the original motivation for rewriting in Go?

[Cartman75]

We do the same thing here but we still use the go version. so I just whipped this script up:

# Lets see what system we are running on
SYSTEM=`uname | tr '[:upper:]' '[:lower:]'`
# Get version
BAZELISKVERSION=`head -1 .bazeliskversion`

# download bazelisk, if needed. Example: https://github.com/bazelbuild/bazelisk/releases/download/v1.4.0/bazelisk-linux-amd64
if [ ! -e ~/.cache/bazelisk/bazelisk-${SYSTEM}-${BAZELISKVERSION} ]; then
  if [ ! -e ~/.cache ]; then
    mkdir ~/.cache
  fi
  if [ ! -e ~/.cache/bazelisk ]; then
    mkdir ~/.cache/bazelisk
  fi
  curl -L https://github.com/bazelbuild/bazelisk/releases/download/v${BAZELISKVERSION}/bazelisk-${SYSTEM}-amd64 --output ~/.cache/bazelisk/bazelisk-${SYSTEM}-${BAZELISKVERSION} --silent
  chmod +x ~/.cache/bazelisk/bazelisk-${SYSTEM}-${BAZELISKVERSION}
fi

# Run bazelisk with flags
~/.cache/bazelisk/bazelisk-${SYSTEM}-${BAZELISKVERSION} ${@}

then create: more .bazeliskversion 1.10.1

Then you can increase the version via git and keep both files local and to the code base it's set for.

This code has worked for us for a while on both mac and Linux, NOT testing at all on windows.

Then run ./bazelisk <whatever to bazel>

[jbms]

It seems you have created bazeliskisk, implemented in posix shell script.

But what is the benefit of this bazeliskisk --- if you want to depend on a posix shell and curl, why not just have your script download bazel directly?

[tradergt]

You can do a lot more with the go version that I really don't want to script for, so I guess it depends on the features you need.

[jwnimmer-tri]

See also https://github.com/golang/go/issues/51900. If Go support for cosmopolitan libc happens, then bazelisk could be a single binary that runs on all platforms, with no dependencies nor per-platform shell script bootstrapping.

[jbms]

Only x86_64, not arm platforms. And I wouldn't be too keen on checking in a bazelisk binary into my repositories.

In any case, the Python version seems to be remaining in fine shape so I don't think there is any issue.

[JayBazuzi]

To the original request ("keep the Python version maintained") there could be a single set of test cases that are run against all the various implementations of bazelisk, to ensure that they are consistent (or at least report where they are not consistent).