Nixos config suddenly complains about sphinx and python version

Help
1

I want to update my nixos configuration flake, which gets its nixpkgs from nixos-unstable branch. It now complains error: sphinx-9.1.0 not supported for interpreter python3.11 Previously it worked fine.

I can’t figure out what exactly caused this to now fail. I didn’t explicitly install or configure sphinx or python except uv, which does not cause this because removing it does not make a difference.

So I guess this sphinx/python dependency is somehow caused here
https://github.com/NixOS/nixpkgs/blob/7869e781b88bbded2d669411f6f0b98ecdaa9d82/nixos/modules/system/etc/etc.nix#L391, however, I cannot figure out why pkgs.buildPackages.python3 now apparently resolves to 311 (previously must have resolved to somthing higher, since it still worked when sphix’ pythonOlder was already changed). nix shell github:nixos/nixpkgs/nixos-unstable#python3Packages.sphinx works fine (nix shell github:nixos/nixpkgs/nixos-unstable#python311Packages.sphinx does not).

Full log:

> nixos-rebuild switch --flake .
warning: Git tree '/home/auser/nixos' is dirty
building the system configuration...
warning: Git tree '/home/auser/nixos' is dirty
error:
       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:37:12:
           36|
           37|   strict = derivationStrict drvAttrs;
             |            ^
           38|

       … while evaluating derivation 'nixos-system-myconfig-26.05.20260227.dd9b079'
         whose name attribute is located at /nix/store/kzqqrhnhh9q3dnrj3x10cdihmj09yc8p-source/pkgs/stdenv/generic/make-derivation.nix:536:13

       … while evaluating attribute 'buildCommand' of derivation 'nixos-system-myconfig-26.05.20260227.dd9b079'
         at /nix/store/kzqqrhnhh9q3dnrj3x10cdihmj09yc8p-source/nixos/modules/system/activation/top-level.nix:64:7:
           63|       passAsFile = [ "extraDependencies" ];
           64|       buildCommand = systemBuilder;
             |       ^
           65|

       … while evaluating the option `environment.etc.dbus-1.source':

       … while calculating requiredPythonModules for python3.11-cherrypy-18.10.0:

       … while calculating requiredPythonModules for python3.11-jaraco-collections-5.2.1:

       … while calculating requiredPythonModules for python3.11-jaraco-text-4.0.0:

       … while calculating requiredPythonModules for python3.11-inflect-7.5.0:

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: sphinx-9.1.0 not supported for interpreter python3.11
Command 'nix --extra-experimental-features 'nix-command flakes' build --print-out-paths '.#nixosConfigurations."myconfig".config.system.build.toplevel' --no-link' returned non-zero exit status 1.
2

The package definition for sphinx limits the python version, which is why 3.11 does not work.

Are you explicitly setting the python version somewhere in your configuration?

3

I didn’t explicitly install or configure sphinx or python except uv, which does not cause this because removing it does not make a difference.

4

Is your config publicly available?

Otherwise –-show-trace option might reveal where the dependency is pulled from.

5

You are using qemu_full, which pulls in ceph, which uses python311. As sphinx no longer supports python311 it fails.

There is a PR to use python312 with ceph.

If you replace qemu_full with qemu you should be able to build.

6

For completeness’ sake, the issue for the build failure is here:

1 Like
7

how would i go about finding this out myself without searching this error message on github and hoping it was already reported by someone else?

why does it talk about python3.11 and not python-3.11 or python311 ?

how do i query “what uses python3.11 in my config?” especially when i can’t build it to investigate? if it does not build, i can’t use nix why-depends and even if i could, how would i find the correct derivation to query if the error only tells me a non-existent name instead of a derivation path or at least correct package name? if i go to my current config in the nix store and fd --follow python | sort | grep 11 it only finds some bash completions, so was this python dependency somehow downgraded from the previously used 3.13 version?

how do i find the definition of packages like qemu_full whose name does not appear in nixpkgs at all? their source link in search.nixos.org leads to another package (here qemu) but this does not show how the two differ? when there is such a package reusing another package’s definition, how can i see where it calls this package function and which arguments it’s using? search.nixos.org should link there…

8

You have to look through the stack trace to see what is going on. It is a fundamental part of debugging. Someone else may be aware of some tools that make this easier with nix’s cryptic error messages.

python311 is the name of an attribute in a nix attribute set that refers to the python interpreter. To use a dot in its name would require quoting, it is cleaner and easier to not use the dot. The python3.11 is used in the package name and it is the package that is being referenced.

I like using nix-tree.

No. Ceph likely always[1]used python311. It has only became apparent that this is the case now because upstream sphinx has dropped support for python311, so the disabled = pythonOlder "3.11”; was changed to 3.12. But because ceph uses python311, and uses sphinx, it broke.

It does appear in nixpkgs.

I agree that it is confusing when search.nixos.org takes you to the definition of qemu.

  1. within recent history ↩︎

1 Like
9

It does appear in nixpkgs .

Hm, sadly github does not show it when searching repo:NixOS/nixpkgs qemu_full. I guess I have to clone every time to search something :frowning:

Well, never mind

10

First of all, cloning nixpkgs is a pain, given that it is just a huge repository in terms of history and commits. While the tree of the latest nixos-unstable is like 40-50MiB, if you do end up cloning it, either be prepared to clone 4GiB or so of history, or make a shallow clone (or a partial clone even).
Just to give a heads-up before you run into this by accident.
However regarding the issue at hand, there’s another way to download nixpkgs; via the tarball/zip export of GitHub itself. This is especially relevant because the nixos-rebuild switch --flake . from the OP does need that code to evaluate it, and it uses exactly that mechanism to download it, meaning it is already on your machine. If you look at the first “while evaluating derivation” error and squint a little, you can even see the path (though without knowing it’s not obvious that this is what it is):

       … while evaluating derivation 'nixos-system-myconfig-26.05.20260227.dd9b079'
         whose name attribute is located at /nix/store/kzqqrhnhh9q3dnrj3x10cdihmj09yc8p-source/pkgs/stdenv/generic/make-derivation.nix:536:13
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ideally you wouldn’t need to hope for the stacktrace to show it, you could either grab it from your flake.lock, or run nix flake metadata to get the path. This has the upside of not just being already on your machine and easy to grep through, it’s also the exact version of nixpkgs which you use to evaluate your config, meaning if an issue was fixed upstream already, or you happen to look at the wrong branch on GitHub[1] the code that Nix tells you is the one which you evaluate against is absolutely the code that has your issue (or at least can reproduce it).

Hope any of this can help in the future.
And as always, you’re welcome to ask about your issues here, we’re happy to help.

  1. I’m not trying to patronize you here. You have no idea how often this happened to me; searching for an issue in code just to find out I’ve been searching on the wrong branch for an hour. Please don’t repeat my mistakes. ↩︎

11

indeed, i usually specify --depth=1 and --branch=nixos-unstable

12

I mean.… technically nixpkgs exposes the path attribute, so you can also run nix build github:NixOS/nixpkgs/nixos-unstable#path and either --out-link or --no-link and --print-out-paths. The following just throws a path to a read-only directory with the code:

nix build --no-link --print-out-paths github:NixOS/nixpkgs/nixos-unstable#path
13

I have the same problem but it was caused by google-fonts

14

This is surprising and I am not able to replicate this issue with google-fonts. The dependencies of google-fonts do not suggest that this issue would affect it.

15

Yeah it’s definitely not google-fonts. likely sambaFull.

16

Oh, sorry, I retested it a bunch more, and it seems to be dupeguru that causes the issue!
Sphinx is listed for doc, so it makes more sense indeed!

I don’t know why it seemed to work when I commented google-fonts in my config, I got things mixed up, I guess.

17

That makes sense. dupeguru is having its python3Packages overridden to use python311Packages in all-packages.nix.

I have opened a PR to address this

1 Like