rules_nixpkgs
rules_nixpkgs copied to clipboard
Add an `interpreter` target to python toolchain.
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: https://github.com/tweag/rules_nixpkgs/blob/9f08fb2322050991dead17c8d10d453650cf92b7/toolchains/python/python.bzl#L80, 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.
+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
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.
Addressed by https://github.com/tweag/rules_nixpkgs/pull/261