Add an interpreter target to python toolchain.

[uri-canva]

rules_python's python_register_toolchains has an interpreter target in its toolchains. Repository rules cannot access toolchains like regular rules can, and they use that target to ensure they're using the same interpreter as the toolchain.

See https://github.com/bazelbuild/rules_python/blob/9cdb4f3f6aded1ccc62a10d004f9927ccc72702f/README.md#toolchain-registration for example.

It would be good if nixpkgs_python_configure did the same thing here:

rules_nixpkgs/toolchains/python/python.bzl

Line 80 in 9f08fb2

py_runtime(

, for example by passing build_file_content to nixpkgs_package:

    build_file_content = """
package(default_visibility = ["//visibility:public"])
filegroup(
    name = "interpreter",
    srcs = ["bin/python"],
)
    """,

Repository rules of other language ecosystems have the same issue, but they don't seem to have a similar pattern (for example rules_jvm_external doesn't provide any way of specifying which java runtime to use other than the regular PATH / JAVA_HOME: https://github.com/bazelbuild/rules_jvm_external/blob/3957fdc382b5a404fccdde74b91c1e614e07e6bd/coursier.bzl#L206.

[dmadisetti]

+1

Currently I get around this by passing in the nix built interpreter for rules_python specific cases

pip_install(
    name = "deps",                                                                                            
    python_interpreter_target = "@python38//:bin/python",                                                     
    requirements = ":requirements.txt",                                                                       
)

Where @python38 comes from nix.
Yes, I know nix can expose pypi packages, but that's no good for non-nix builds

[aherrmann]

Agreed, that sounds like a useful feature.

Worth noting, the current setup doesn't generate an executable file within Bazel's execroot, instead it points directly into the Nix store, see here for the reasoning behind that. That said, creating a single bin/python symlink shouldn't be an issue.

Another thing worth noting, rules_nixpkgs provided toolchains are very careful to separate the external workspace that defines the toolchain from the external workspace(s) that hold the actual Nix imports. This is to ensure that the Nix dependencies are fetched lazily, and to support non-Nix use-cases (e.g. Windows). So, as proposed by @uri-canva, the interpreter target and the bin/python symlink probably have to sit within the workspace that defines the py_runtime target. That said, it should be possible for _nixpkgs_python_toolchain to generate a defs.bzl file that exports an interpreter like rules_python does.

[aherrmann]

Addressed by #261