buildPython*: pass check-related args whenever specified

[ShamrockLee]

Pass

• disabledTests
• disabledTestPaths
• pytestFlags
• pytestFlagsArray
• unittestFlags
• unittestFlagsArray

whenever they are specified,
no matter if doCheck is true or if they are empty lists.

This PR simplifies the buildPython* argument handling and brings us closer to deprecating overridePythonAttrs and adopting fixed-point arguments.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

Any idea why it was done the way it was done before?

[ShamrockLee]

Any idea why it was done the way it was done before?

The doCheck guard is added in #327264, saying it would be "useful when running the tests separately in passthru.tests."

I doubt guarding the flags this way would be as effective as intended, as neither checkPhase (installCheckPhase) nor checkInputs (installCheckInputs) are guarded.

[wolfgangwalther]

To achieve the effect, wouldn't we need to guard this on separateChecks somehow?

Edit: Ah, #272177 wasn't even merged. So it seems like the guards will only be useful once that's done, right?

[ShamrockLee]

To achieve the effect, wouldn't we need to guard this on separateChecks somehow?

The original PR was an initial effort for #272177, but it was unfortunately closed due to author burnout.

It is more practical to re-work the guard if someone wants to pick up the automatic-passthru-test work.

[ShamrockLee]

Edit: Ah, #272177 wasn't even merged. So it seems like the guards will only be useful once that's done, right?

I think so.

[ShamrockLee]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 376060

---

x86_64-linux

[natsukium]

Some Python packages, especially scientific ones, have expensive tests.
Their compilation time is also usually expensive because they are written in C++, Rust, etc.
Therefore, such packages already separate their tests into passthru.tests, even if separateChecks is not implemented.

I doubt guarding the flags this way would be as effective as intended, as neither checkPhase (installCheckPhase) nor checkInputs (installCheckInputs) are guarded.

In python packages, checkPhase is provided by pytestCheckHook in most cases, so it is unlikely to be changed.
While nativeCheckInputs may be worth blocking, I think we already block the attributes we most often change to make tests green.

However, I do not intend to prevent our ideals with these hacks, so I believe we could remove it if necessary.

[ShamrockLee]

Therefore, such packages already separate their tests into passthru.tests, even if separateChecks is not implemented.

I understand this as we add such guards as a shorthand to "move" the attributes to passthru.tests so we could write, e.g., passthru.tests.check = self.overridePythonAttrs { doCheck = true; }; without having to manually place all the check-related attributes under the definition of passthru.tests.check. Is that correct?

If so, why do people not just define the check-related attributes under the package test definition (e.g., the passthru.tests.check above)?