--workspace_status_command cannot easily be made platform-independent (Windows/Linux)

[Xjs]

Description of the problem:

The --workspace_status_command will be executed from /bin/sh under Linux (and macOS I think) and from CMD.EXE under Windows. This makes it difficult to conceive a workspace status script that has the same output on both platforms.

It should either be possible to specify different commands for different architectures on the command line, or some guarantees about execution environments of the workspace status command should be made (such as run everything through BAZEL_SH).

Feature requests: what underlying problem are you trying to solve with this feature?

We use committed tools/bazel.rc files to execute a workspace status script that is also committed to the repository.

Our current workaround is to include a script called workspace.bat that contains effectively the following:

:; ./tools/workspace_status.sh
:; exit
@ECHO OFF
cd tools
workspace_status.cmd

with workspace_status.sh and workspace_status.cmd containing a sh and CMD.EXE implementation of the same commands (essentially some git rev-list with some output processing).

The above is a hybrid bash/cmd executable script as inspired by https://stackoverflow.com/questions/17510688/single-script-to-run-in-both-windows-batch-and-linux-bash

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Create a bazel workspace containing a tools directory with a bazel.rc file containing

build --workspace_status_command="tools/workspace_status.bat"

e. g. with the .bat file described above
2. Bazel build on Windows
3. Observe the .bat file being executed with CMD.EXE
4. Bazel build on Linux
5. Observe the .bat file being executed with /bin/sh

[aiuto]

This is split between Windows and External Deps. You can figure out who really should do the work.

[laszlocsomor]

FYI, as a workaround you can use a Python script. Demo: https://github.com/laszlocsomor/projects/tree/master/bazel/workspace-status

[Xjs]

FYI, as a workaround you can use a Python script. Demo: https://github.com/laszlocsomor/projects/tree/master/bazel/workspace-status

Thanks for the hint & demo, that seems like a good idea.

Just to make sure: Does bazel always depend on Python, i. e. can we be 100% sure a python interpreter is in PATH? (From https://docs.bazel.build/versions/master/install-windows.html it looks like it could be omitted on Windows, all other build/install docs on bazel.build state it is a hard prerequisite)

[laszlocsomor]

No, it's not guaranteed that Python's always available.
Therefore the workaround is limited to the case when you know Python is available, for example if your team builds Python rules so everyone has it installed. (I took this idea from the NodeJS folks, who do the same trick with node, knowing everyone has it on their machine: #4802 (comment))

FYI, there's more context here: #5002.

[filipesilva]

In our case we have a JS project, so we can expect NodeJS to be globally available.

I wonder how feasible it would be to run a target as the workspace status command though... That way a .sh script could be used when sourced through native.sh_binary.

[xondrejk]

While Python is a compelling option, it comes with its own cross-platform challenge as the demo itself shows. Namely for Python3 users currently python still tends to refer to Python2 on Linux whereas on Windows Python3 executable is normally called just python.exe i.e. without additional host preparation there isn't a uniform way to call the same version of the interpreter. Presumably the workspace file can be trivial enough to not care about language version (or start with short logic to execve() python3 on Linux), but essentially a platform specific --workspace_status_command would still be useful.

[Xjs]

If going for python, I think everything else except making sure that python3 is used consistently on every platform would be very unwise.

[meteorcloudy]

https://docs.bazel.build/versions/4.2.2/command-line-reference.html#flag--enable_platform_specific_config could probably help ease this issue, there is nothing we can do to the --workspace_status_command itself.