Workspace rules don't have the access to the bazel's toolchains

There is a group of workspace rules that invoke package managers for various languages. Workspace rules currently don’t have an access to bazel’s toolchains for corresponding languages. As a result, package manager is invoked with the incorrect toolchain information, or project owners have to use multiple workspace rules (one for each toolchain) and select the right one in their BUILD files. In the second case, the toolchain information has to be duplicated in the WORKSPACE file, as there is currently no way to reuse toolchain information.

As a more concrete example: pip_import python workspace rule invokes pip package manager, but since it doesn’t have access to the C++ toolchain, it compiles native code for the host system. When someone needs to target a different platform, they would need to have multiple pip_import rules in their WORKSPACE and use select in their deps. The workspace rules would have to provide environment variables specifying the compiler, linker, and the corresponding flags. This information is already present in the CROSSTOOL file, but cannot be easily reused.

In addition, if the project uses hermetic C++ toolchain (toolchain files are part of the project, as opposed by being installed on the host system), then it’s even more complicated, since to get the C++ compiler one would have to execute bazel.

[hlopko]

I understand that this issue goes against many principles of Bazel. But it’s good to be aware of this problem and evaluate the possibilities, even when the “fix” is to document best practices when writing workspace rules integrating with language specific package managers.

I’d assume that it’s not easy to persuade pip, npm, rubygems, cargo and many other language specific package managers not to build the package, but to provide sources only. But I know at least of https://github.com/pinterest/PodToBUILD (@jerrymarino) that pulls this off for cocoa pods.

[hlopko]

Closing as invalid (wont fix).