Add mach-nix example for python repository

.bazelrc.common

@@ -3,6 +3,8 @@ build --host_platform=@rules_nixpkgs_core//platforms:host
 build:bzlmod --enable_bzlmod
 build:bzlmod --registry=https://bcr.bazel.build
 
+test --test_output=errors
+
 # User Configuration
 # ------------------
 try-import %workspace%/.bazelrc.local

README.md

@@ -1867,18 +1867,26 @@ sets with nixpkgs. See our python [`tests`](/testing/toolchains/python) and
 This rule is intended to mimic as closely as possible the [rules_python
 API](https://github.com/bazelbuild/rules_python#using-the-package-installation-rules).
 `nixpkgs_python_repository` should be a drop-in replacement of `pip_parse`.
-As such, it also provides a `requirement` function to perform the name
-mangling. Using the `requirement` fucntion inherits the same advantages and
+As such, it also provides a `requirement` function.
+
+:warning: Using the `requirement` fucntion inherits the same advantages and
 limitations as the one in rules_python. All the function does is create a
 label of the form `@{nixpkgs_python_repository_name}//:{package_name}`.
 While depending on such a label directly will work, the layout may change
 in the future. To be on the safe side, define and import your own
 `requirement` function if you need to play with these labels.
 
+:warning: Just as with rules_python, nothing is done to enforce consistency
+between the version of python used to generate this repository and the one
+configured in your toolchain, even if you use nixpkgs_python_toolchain. You
+should ensure they both use the same python from the same nixpkgs version.
+While nixpkgs_python_repository could also register the toolchain used to
+generate the package set, this is not implemented yet.
+
 :warning: packages names exposed by this rule are determined by the `pname`
-attribute of the nix packages. These may vary slightly from names used by
-rules_python. Should this be a problem, you can provide you own
-`requirement` function.
+attribute of the corresponding nix package. These may vary slightly from
+names used by rules_python. Should this be a problem, you can provide you
+own `requirement` function, for example one that lowercases its argument.
 
 
 #### Parameters

testing/python/MODULE.bazel

@@ -53,3 +53,5 @@ register_toolchains("@nixpkgs_python_toolchain//:all")
 
 use_repo(non_module_deps, "generated_poetry_packages_deps")
 use_repo(non_module_deps, "poetry_packages")
+use_repo(non_module_deps, "generated_mach_nix_packages_deps")
+use_repo(non_module_deps, "mach_nix_packages")

testing/python/mach-nix.nix

@@ -0,0 +1,26 @@
+let
+  mach-nix = import (builtins.fetchGit {
+    url = "https://github.com/DavHau/mach-nix";
+    ref = "f60b9833469adb18e57b4c9e8fc4804fce82e3da";
+  }) {
+    # ** Extremely important! **
+    # You want to use the same python version as your main nixpkgs.
+    # Bazel does not enforce this, and it will fail for binary packages.
+    pkgs = import <nixpkgs> {};
+  };
+  pythonWithPackages = mach-nix.mkPython {
+    requirements = builtins.readFile ./requirements.txt;
+    providers._default = "nixpkgs";
+  };
+  python = pythonWithPackages; #.python;
+  # Beloved hacks !
+  # Extract the subset of packages that have been requested by mach-nix.
+  # By default, python.pkgs contains all the packages known by nixpkgs,
+  # plus the onse configured by mach-nix.
+  # This retrives the `extraLibs` attribute that mach-nix configured.
+  pkgs = (pythonWithPackages.override (old: {
+    ignoreCollisions = old.extraLibs;
+  })).ignoreCollisions;
+in {
+  inherit python pkgs;
+}

testing/python/requirements.txt

@@ -0,0 +1,2 @@
+cffi
+pandas

testing/python/tests/BUILD.bazel

@@ -1,5 +1,6 @@
 load("@nixpkgs_python_toolchain//:defs.bzl", "interpreter")
 load("@poetry_packages//:requirements.bzl", poetry_requirement = "requirement")
+load("@mach_nix_packages//:requirements.bzl", mach_nix_requirement = "requirement")
 package(default_testonly = 1)
 
 # Test nixpkgs_python_configure() by running some Python code.
@@ -35,3 +36,17 @@ py_test(
     size = "small",
     visibility = ["//visibility:public"],
 )
+
+py_test(
+    name = "import-mach-nix-packages",
+    main = "import_packages_test.py",
+    srcs = ["import_packages_test.py"],
+    deps = [
+        mach_nix_requirement("cffi"),
+        mach_nix_requirement("pandas"),
+    ],
+    srcs_version = "PY3",
+    python_version = "PY3",
+    size = "small",
+    visibility = ["//visibility:public"],
+)

testing/python/tests/import_packages_test.py

@@ -1,3 +1,7 @@
+import sys, pprint
+print("python path = ", end="")
+pprint.pprint(sys.path)
+
 import cffi
 print("cffi version = ", cffi.__version__)
 

testing/python/tests/nixpkgs_repositories.bzl

@@ -50,3 +50,12 @@ def nixpkgs_repositories(*, bzlmod):
             "//:poetry.lock",
         ],
     )
+
+    nixpkgs_python_repository(
+        name = "mach_nix_packages",
+        repository = "@nixpkgs",
+        nix_file = "//:mach-nix.nix",
+        nix_file_deps = [
+            "//:requirements.txt",
+        ],
+    )

toolchains/python/README.md

@@ -266,18 +266,26 @@ sets with nixpkgs. See our python [`tests`](/testing/toolchains/python) and
 This rule is intended to mimic as closely as possible the [rules_python
 API](https://github.com/bazelbuild/rules_python#using-the-package-installation-rules).
 `nixpkgs_python_repository` should be a drop-in replacement of `pip_parse`.
-As such, it also provides a `requirement` function to perform the name
-mangling. Using the `requirement` fucntion inherits the same advantages and
+As such, it also provides a `requirement` function.
+
+:warning: Using the `requirement` fucntion inherits the same advantages and
 limitations as the one in rules_python. All the function does is create a
 label of the form `@{nixpkgs_python_repository_name}//:{package_name}`.
 While depending on such a label directly will work, the layout may change
 in the future. To be on the safe side, define and import your own
 `requirement` function if you need to play with these labels.
 
+:warning: Just as with rules_python, nothing is done to enforce consistency
+between the version of python used to generate this repository and the one
+configured in your toolchain, even if you use nixpkgs_python_toolchain. You
+should ensure they both use the same python from the same nixpkgs version.
+While nixpkgs_python_repository could also register the toolchain used to
+generate the package set, this is not implemented yet.
+
 :warning: packages names exposed by this rule are determined by the `pname`
-attribute of the nix packages. These may vary slightly from names used by
-rules_python. Should this be a problem, you can provide you own
-`requirement` function.
+attribute of the corresponding nix package. These may vary slightly from
+names used by rules_python. Should this be a problem, you can provide you
+own `requirement` function, for example one that lowercases its argument.
 
 
 #### Parameters

toolchains/python/python.bzl

@@ -280,18 +280,26 @@ def nixpkgs_python_repository(
     This rule is intended to mimic as closely as possible the [rules_python
     API](https://github.com/bazelbuild/rules_python#using-the-package-installation-rules).
     `nixpkgs_python_repository` should be a drop-in replacement of `pip_parse`.
-    As such, it also provides a `requirement` function to perform the name
-    mangling. Using the `requirement` fucntion inherits the same advantages and
+    As such, it also provides a `requirement` function.
+
+    :warning: Using the `requirement` fucntion inherits the same advantages and
     limitations as the one in rules_python. All the function does is create a
     label of the form `@{nixpkgs_python_repository_name}//:{package_name}`.
     While depending on such a label directly will work, the layout may change
     in the future. To be on the safe side, define and import your own
     `requirement` function if you need to play with these labels.
 
+    :warning: Just as with rules_python, nothing is done to enforce consistency
+    between the version of python used to generate this repository and the one
+    configured in your toolchain, even if you use nixpkgs_python_toolchain. You
+    should ensure they both use the same python from the same nixpkgs version.
+    While nixpkgs_python_repository could also register the toolchain used to
+    generate the package set, this is not implemented yet.
+
     :warning: packages names exposed by this rule are determined by the `pname`
-    attribute of the nix packages. These may vary slightly from names used by
-    rules_python. Should this be a problem, you can provide you own
-    `requirement` function.
+    attribute of the corresponding nix package. These may vary slightly from
+    names used by rules_python. Should this be a problem, you can provide you
+    own `requirement` function, for example one that lowercases its argument.
 
     Args:
       name: The name for the created package set.