python3Packages.setuptools-rust: fix cross build for all `setuptools-rust` based packages by DavHau · Pull Request #467817 · NixOS/nixpkgs

DavHau · 2025-12-04T12:33:17Z

Prior to this change all python packages using setuptools-rust were broken when cross compiled as they built binaries for the build platform instead of for the host platform.

The setuptoolsRustBuildHook hook would have to be included as a native build input instead of the setuptools-rust package, but practically wasn't used anywhere.

This change makes it so that setuptoolsRustBuildHook becomes unnecessary, and instead setuptools-rust propagates a setup-hook directly setting up the build environment, similar to how cmake does it when included via nativeBuildInputs.

This change fixes cross on all packages using setuptools-rust as a build-system.

Things done

Add a 👍 reaction to pull requests you find important.

pkgs/development/interpreters/python/hooks/default.nix

dotlambda · 2025-12-04T22:43:20Z

Commit messages should probably start with python3Packages.setuptools-rust:

pkgs/development/python-modules/setuptools-rust/default.nix

…rust` based packages Prior to this change all python packages using `setuptools-rust` were broken when cross compiled as they built binaries for the build platform instead of for the host platform. The setuptoolsRustBuildHook hook would have to be included as a native build input instead of the `setuptools-rust` package, but practically wasn't used anywhere. This change makes it so that `setuptoolsRustBuildHook` becomes unnecessary, and instead `setuptools-rust` propagates a setup-hook directly setting up the build environment, similar to how cmake does it when included via nativeBuildInputs. This change fixes cross on all packages using `setuptools-rust` as a build-system.

Aleksanaa · 2025-12-22T13:33:59Z

pkgs/development/python-modules/setuptools-rust/default.nix

+      null
+    else
+      replaceVars ./setuptools-rust-hook.sh {
+        pyLibDir = "${targetPackages.python3}/lib/${targetPackages.python3.libPrefix}";


The default version of python is incorrectly introduced here, instead of the correct one corresponding to python3Packages.

This is causing python312Packages.bcrypt to fail in staging-next, and potentially other packages, because pyo3 tries to use a higher version than current system, resulting in incompatible symbols.

Due to an issue [1] in the Python splices uncovered by the setuptools-rust cross compilation fix [2], some dependencies will otherwise fail to build. Unfortunately this actually means losing the tests when the build platform can execute host binaries (such as in `pkgsStatic`), but there's not a lot one can do about this without fixing the Python splicing. [1] NixOS#476822 [2] NixOS#467817

Due to an issue [1] in the Python splices uncovered by the setuptools-rust cross compilation fix [2], some dependencies will otherwise fail to build. Unfortunately this actually means losing the tests when the build platform can execute host binaries (such as in `pkgsStatic`), but there's not a lot one can do about this without fixing the Python splicing. [1] #476822 [2] #467817 (cherry picked from commit aba5e58)

Due to an issue [1] in the Python splices uncovered by the setuptools-rust cross compilation fix [2], some dependencies will otherwise fail to build. Unfortunately this actually means losing the tests when the build platform can execute host binaries (such as in `pkgsStatic`), but there's not a lot one can do about this without fixing the Python splicing. [1] NixOS#476822 [2] NixOS#467817

jmbaur · 2026-01-10T03:39:04Z

I think this is the change that broke cross-compiling the linux kernel for (e.g.) armv7 targets. Due to ubootTools being used in nativeBuildInputs of the kernel derivation, one can reproduce the failure with nix build nixpkgs#pkgsCross.armv7l-hf-multiplatform.pkgsBuildHost.ubootTools and notice some python bcrypt dependency fails to build. That ends up being because of this line, which pulls in pyopenssl (depends on failing bcrypt). I'm not sure exactly on how this can best be resolved. Is it the fault of this change? Is it being done incorrectly on the ubootTools side?

Due to an issue [1] in the Python splices uncovered by the setuptools-rust cross compilation fix [2], some dependencies will otherwise fail to build. Unfortunately this actually means losing the tests when the build platform can execute host binaries (such as in `pkgsStatic`), but there's not a lot one can do about this without fixing the Python splicing. [1] NixOS#476822 [2] NixOS#467817

Commit e656303 (PR NixOS#467817) made `setuptools-rust` work automatically in cross compilation scenarios by replacing `setuptoolsRustBuildHook` with `setuptools-rust.setupHook`. However it mixed cross compilation stage variables in the variables injected (substituted) to the setup hook. The variables injected in this commit are identical to those that were used prior to e656303, but in `setuptoolsRustBuildHook`. Should fix this report: NixOS#467817 (comment)

doronbehar

The intention of this PR is good and it is mostly well written, but I too encountered the issue quoted below, and #473299 didn't fix it.

I think this is the change that broke cross-compiling the linux kernel for (e.g.) armv7 targets. Due to ubootTools being used in nativeBuildInputs of the kernel derivation, one can reproduce the failure with nix build nixpkgs#pkgsCross.armv7l-hf-multiplatform.pkgsBuildHost.ubootTools and notice some python bcrypt dependency fails to build. That ends up being because of this line, which pulls in pyopenssl (depends on failing bcrypt). I'm not sure exactly on how this can best be resolved. Is it the fault of this change? Is it being done incorrectly on the ubootTools side?

@DavHau Could you share a nix build command that reproduces the issue you encountered? I can share a command that fails now:

nix build -Lf. pkgsCross.armv7l-hf-multiplatform.buildPackages.python3.pkgs.bcrypt

Per my review comment below, I open the following:

#480005

~~EDIT: But it is not fully functional. See comments within.~~ It is functional now.

doronbehar · 2026-01-14T10:50:23Z

pkgs/development/interpreters/python/hooks/default.nix

-      substitutions = {
-        pyLibDir = "${python}/lib/${python.libPrefix}";
-        cargoBuildTarget = stdenv.hostPlatform.rust.rustcTargetSpec;
-        cargoLinkerVar = stdenv.hostPlatform.rust.cargoEnvVarTarget;


Why didn't you use these variables in the setputools-rust.setupHook?

Commit e656303 (PR NixOS#467817) made `setuptools-rust` work automatically in cross compilation scenarios by replacing `setuptoolsRustBuildHook` with `setuptools-rust.setupHook`. However it mixed cross compilation stage variables in the variables injected (substituted) to the setup hook. The variables injected in this commit are identical to those that were used prior to e656303, but in `setuptoolsRustBuildHook`. Should fix this report: NixOS#467817 (comment)

Commit e656303 (PR NixOS#467817) made `setuptools-rust` work automatically in cross compilation scenarios by replacing `setuptoolsRustBuildHook` with `setuptools-rust.setupHook`. However it broke builds such as: ```sh nix build -Lf. pkgsCross.armv7l-hf-multiplatform.buildPackages.python3.pkgs.cryptography ``` As reported here: NixOS#467817 (comment) This adjustment fixes the above build, while also maintaining the following working: ```sh nix build -Lf. pkgsCross.armv7l-hf-multiplatform.python3.pkgs.libcst ```

Due to an issue [1] in the Python splices uncovered by the setuptools-rust cross compilation fix [2], some dependencies will otherwise fail to build. Unfortunately this actually means losing the tests when the build platform can execute host binaries (such as in `pkgsStatic`), but there's not a lot one can do about this without fixing the Python splicing. [1] NixOS#476822 [2] NixOS#467817

Commit e656303 (PR NixOS#467817) made `setuptools-rust` work automatically in cross compilation scenarios by replacing `setuptoolsRustBuildHook` with `setuptools-rust.setupHook`. However it broke builds such as: ```sh nix build -Lf. pkgsCross.armv7l-hf-multiplatform.buildPackages.python3.pkgs.cryptography ``` As reported here: NixOS#467817 (comment) This adjustment fixes the above build, while also maintaining the following working: ```sh nix build -Lf. pkgsCross.armv7l-hf-multiplatform.python3.pkgs.libcst ```

Due to an issue [1] in the Python splices uncovered by the setuptools-rust cross compilation fix [2], some dependencies will otherwise fail to build. Unfortunately this actually means losing the tests when the build platform can execute host binaries (such as in `pkgsStatic`), but there's not a lot one can do about this without fixing the Python splicing. [1] #476822 [2] #467817 (cherry picked from commit aba5e58)

ofborg bot added the 6.topic: cross-compilation Building packages on a different platform than they will be used on label Dec 4, 2025

DavHau mentioned this pull request Dec 4, 2025

python3Packages.tiktoken: fix cross build #467796

Closed

13 tasks

nixpkgs-ci bot requested review from adevress, benaryorg, johanot, krav, mweinelt, natsukium and nh2 December 4, 2025 12:41

DavHau mentioned this pull request Dec 4, 2025

python3Packages.bcrypt: fix cross build #467741

Closed

13 tasks

SuperSandro2000 reviewed Dec 4, 2025

View reviewed changes

pkgs/development/interpreters/python/hooks/default.nix Outdated Show resolved Hide resolved

happysalada approved these changes Dec 4, 2025

View reviewed changes

nixpkgs-ci bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Dec 4, 2025

DavHau force-pushed the setuptools-rust branch from a31168d to 09d999f Compare December 7, 2025 08:06

DavHau requested a review from SuperSandro2000 December 7, 2025 08:08

DavHau force-pushed the setuptools-rust branch from 09d999f to 40c1e0e Compare December 7, 2025 08:12

dotlambda changed the title ~~python3Packages: fix cross build for all setuptools-rust based packages~~ python3Packages.setuptools-rust: fix cross build for all setuptools-rust based packages Dec 7, 2025

dotlambda reviewed Dec 7, 2025

View reviewed changes

pkgs/development/python-modules/setuptools-rust/default.nix Outdated Show resolved Hide resolved

dotlambda reviewed Dec 7, 2025

View reviewed changes

pkgs/development/python-modules/setuptools-rust/default.nix Outdated Show resolved Hide resolved

DavHau force-pushed the setuptools-rust branch from 40c1e0e to ffc0702 Compare December 9, 2025 03:51

DavHau requested a review from dotlambda December 9, 2025 03:51

DavHau force-pushed the setuptools-rust branch from ffc0702 to e656303 Compare December 9, 2025 05:32

dotlambda added this pull request to the merge queue Dec 11, 2025

Merged via the queue into NixOS:staging with commit 195e2bc Dec 11, 2025
27 of 29 checks passed

Aleksanaa reviewed Dec 22, 2025

View reviewed changes

Aleksanaa mentioned this pull request Dec 22, 2025

python3Packages.setuptools-rust: fix python version inconsistency #473299

Merged

13 tasks

doronbehar reviewed Jan 14, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

python3Packages.setuptools-rust: fix cross build for all `setuptools-rust` based packages#467817

python3Packages.setuptools-rust: fix cross build for all `setuptools-rust` based packages#467817
dotlambda merged 1 commit intoNixOS:stagingfrom
DavHau:setuptools-rust

DavHau commented Dec 4, 2025

Uh oh!

Uh oh!

dotlambda commented Dec 4, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Aleksanaa Dec 22, 2025

Uh oh!

jmbaur commented Jan 10, 2026

Uh oh!

doronbehar left a comment •

edited

Loading

Uh oh!

doronbehar Jan 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

DavHau commented Dec 4, 2025

Things done

Uh oh!

Uh oh!

dotlambda commented Dec 4, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Aleksanaa Dec 22, 2025

Choose a reason for hiding this comment

Uh oh!

jmbaur commented Jan 10, 2026

Uh oh!

doronbehar left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

doronbehar Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

doronbehar left a comment •

edited

Loading