//toolchain/tools:llvm_release_name.py should be exposed as a py_binary

[Kernald]

In toolchains/rules.bzl:

https://github.com/grailbio/bazel-toolchain/blob/b40c6282c232212006ba184ef4d4a198322d5a38/toolchain/rules.bzl#L52-L56

@com_grail_bazel_toolchain//toolchain/tools:llvm_release_name.py is used directly, and executed there:

https://github.com/grailbio/bazel-toolchain/blob/7739fd455d83e5594150bdab8178d408651e1390/toolchain/internal/llvm_distributions.bzl#L71-L75

This is fine on Linux as the script is executable. However, Windows shows the issue with that: it expects a Win32 binary, which a Python script isn't. While Windows support wouldn't be fixed just by changing that (the LLVM distribution is an installable package on Windows, I don't think they provide a simple archive, sadly), this script should be wrapped as a py_binary. This would also prevent potential issues if this script isn't compatible with either Python 2 or Python 3, as there's currently nothing enforcing one version over the other - it uses whatever $(which python) points to.

[siddharthab]

Hi!

Thank you for looking into this. Unfortunately, build artifacts can not be used in repository rules. Bazel has three distinct sequential phases -- loading, analysis and build. Repository rules are executed in the loading phase, so they can not depend on anything from the analysis or build phases.

The script has to be directly executed or interpreted. What we can do instead is provide the script as an argument to the python interpreter which will not rely on the unix specific shebang line mechanism. Sounds good?

[Kernald]

Oh, you're right, sorry, I didn't think about that. Calling the Python interpreter sounds like a good solution indeed.

[siddharthab]

Closing this issue because the solution to the problem is something else. The exact solution can be determined when working on Windows support.