Overwrite the `disabledTests` of a failing Python dependencies in NixOS

Hello there,

first of all: this is my first post in this Discourse forum and I’m fairly new to Nix & NixOS.
I’d appreciate for any enhancement in the structuring and context-giving of this post.


I tried to compile my NixOS config using the nixpkgs.localSystem attribute set to create a build environment that is adjusted as well as possible to my CPU.
Here’s a code snippet from my configuration.nix:

nix.settings.system-features = [ "nixos-test" "benchmark" "big-parallel" "kvm" "gccarch-alderlake" ];
nixpkgs.localSystem = {
    gcc.arch = "alderlake";
    gcc.tune = "alderlake";
    system = "x86_64-linux";

The first issue I ran into was that the max amount of files on my system was reached by the nix daemon, to fix this I used $ ulimit -n 65535.
(this shouldn’t be necessary to check, but here is a reference to my NixOS config’s current HEAD)

The Problem

The problem occurred when I got to the point where my day-to-day software was about be compiled.
When assembling the python311Packages.curio & python311Packages.numpy packages I noticed a few tests were failing. Here’s the log for curio:

error: builder for '/nix/store/qa59695s5n7fn47akswxhyw55lnxvj90-python3.11-curio-1.6.drv' failed with exit code 1;
       last 10 log lines:
       >   /build/curio-1.6/tests/test_thread.py:266: RuntimeWarning: coroutine 'simple_coro' was never awaited
       >     with pytest.raises(AsyncOnlyError):
       >   Enable tracemalloc to get traceback where the object was allocated.
       >   See https://docs.pytest.org/en/stable/how-to/capture-warnings.html#resource-warnings for more info.
       > -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
       > =========================== short test summary info ============================
       > FAILED tests/test_workers.py::test_cpu - AssertionError: assert [10, 9, 8, 7, 6, 5, ...] == [10, 9, 8, 7, 6, 5, ...]
       > = 1 failed, 254 passed, 4 skipped, 4 deselected, 10 warnings in 88.74s (0:01:28) =
       > /nix/store/zzijgp96zlfbpggbs4dyyqcrpxcjhk1m-stdenv-linux/setup: line 1559: pop_var_context: head of shell_variables not a function context

I just tried to ignore by declaring an overlay in my systems NixOS flake.nix to disable these tests for those failing packages.
Here is a abbreviation of it (and only for the numpy package):

  outputs = input-attrs@{ /*...*/ ... }:
      current-system = "x86_64-linux";
      overlay-unstable = self: super: { /*...*/ };
      nixosConfigurations = {
        dnix = nixpkgs.lib.nixosSystem {
          system = current-system;
          specialArgs = { /*...*/; };
          modules = [
            ({ config, pkgs, lib, ... }: {
              nixpkgs.overlays = [
                # Quick build error fixes
                (final: prev: {
                  python311Packages = prev.python311Packages //
                    numpy = prev.python311Packages.numpy.overrideAttrs (oldAttrs: {
                      disabledTests = [
                      ] ++ oldAttrs.disabledTests;
// ...

But htis just seems to don’t do anything. The specified tests would keep failing and crushing my systems compilation due to an unavoidable dependency on numpy/ curio.
And the worst of all: I have no idea why.

Things I did just to make sure…

  • Queried nix repl while altering the overlays arguments etc.
:lf ./dotfiles.nix
[ "test_validate_transcendentals" "test_structured_object_item_setting[<subarray>]" ]
  • Tried to use overridePythonAttrs instead of the overrideAttrs to create the overlay
  • Set the doInstallCheck attribute in the derivation to false
  • Tried to mess around with the pytestFlagsArray attribute in the derivation


I’m pretty desperate at this point and thought about reaching out to the community, which I now did.
Any ideas how to get out of this misery?

I went through similar problems, and can confirm that trying to override Python packages can make you desperate…

For me, it turned out that overriding using pythonPackagesExtensions (see https://github.com/NixOS/nixpkgs/blob/e52b59f96b04a7c87a68596ea36577460574c654/doc/languages-frameworks/python.section.md#how-to-override-a-python-package-for-all-python-versions-using-extensions-how-to-override-a-python-package-for-all-python-versions-using-extensions or Overriding Python Modules - #7 by Ozone6418 for examples) is much more robust for Python packages.

1 Like

Than you for the fast and nice answer!!
How the heck should I’ve ever managed to come to this?
I just started a rebuild of the whole system. Lets see where that will take me this time…

Edit: The tests indeed are getting skipped now. Thanks again! :smile:


Well, really no reason to blame yourself. I also failed a while ago, despite going through various code samples I found: How to override a Python package using callPackage from an overlay

While I would generally think the documentation would deserve more love, one thing I took from that experience is that it’s worth looking into the language framework documentation in the git repo (https://github.com/NixOS/nixpkgs/tree/master/doc/languages-frameworks) for such issues specific to one programming language. Considering that new facilities in the programming language frameworks get developed in the git repo, it may be more likely that the documentation therein is also up-to-date, compared with documentation where the developer might even need a separate login to update it.