python3Packages.shiboken2: reverse dependencies have to use python312

[dotlambda]

python313.pkgs.shiboken2 fails to build with

In file included from /build/pyside-setup-opensource-src-5.15.16/sources/shiboken2/libshiboken/sbkpython.h:104,
                 from /build/pyside-setup-opensource-src-5.15.16/sources/shiboken2/libshiboken/sbkarrayconverter.h:43,
                 from /build/pyside-setup-opensource-src-5.15.16/sources/shiboken2/libshiboken/sbkarrayconverter.cpp:40:
/build/pyside-setup-opensource-src-5.15.16/sources/shiboken2/libshiboken/sbkarrayconverter.cpp: In function 'void Shiboken::Conversions::sequenceToCppIntArray(PyObject*, void*)':
/build/pyside-setup-opensource-src-5.15.16/sources/shiboken2/libshiboken/pep384impl.h:187:24: error: '_PyLong_AsInt' was not declared in this scope; did you mean 'PyLong_AsInt'?
  187 | #define _PepLong_AsInt _PyLong_AsInt
      |                        ^~~~~~~~~~~~~
/build/pyside-setup-opensource-src-5.15.16/sources/shiboken2/libshiboken/sbkarrayconverter.cpp:164:29: note: in expansion of macro '_PepLong_AsInt'
  164 |     convertPySequence(pyIn, _PepLong_AsInt, handle->data());
      |                             ^~~~~~~~~~~~~~
make[2]: *** [libshiboken/CMakeFiles/libshiboken.dir/build.make:155: libshiboken/CMakeFiles/libshiboken.dir/sbkarrayconverter.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:354: libshiboken/CMakeFiles/libshiboken.dir/all] Error 2

It was marked broken in #407932.

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/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (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, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[LordGrimmauld]

cc @pbsds who recently wanted to unpin python 3.11 and also (unknowingly) ran into this exact thing for some packages

[LordGrimmauld]

I'll go through the full list soon.
The alternative is to "soft-pin":

pythonPackages' =
    # lib.meta.availableOn does not respect meta.broken?
    if python3Packages.shiboken2.meta.available then python3Packages else python312Packages;

See #416726 for source

A hard-pin on 3.12 seems fine, shiboken2 getting 3.13 support is very unlikely. A soft-pin like this is an option, as that will then silently update python once shiboken updates.

[LordGrimmauld]

nixpkgs/pkgs/development/python-modules/napari/default.nix

Line 23 in ee930f9

magicgui,

napari/napari-npe2 also depend on shiboken2 via shiboken2 -> pyside2 -> magicgui
Those probably need similar treatment. However, napari is buildPythonPackage for whatever reason...

[dotlambda]

However, napari is buildPythonPackage for whatever reason...

It seems to have a Python API: https://github.com/napari/napari?tab=readme-ov-file#simple-example

[LordGrimmauld]

SuperQT depends on pyside2 -> shiboken:

nixpkgs/pkgs/development/python-modules/superqt/default.nix

Line 47 in ee930f9

pyside2 = [ pyside2 ];

However it is marked optional - can we just disable pyside2 for python 3.13+ on superqt?

Otherwise, these might go wonky:

nixpkgs/pkgs/by-name/li/linien-gui/package.nix

Line 41 in ee930f9

superqt

nixpkgs/pkgs/by-name/ty/typstwriter/package.nix

Line 26 in ee930f9

superqt

[LordGrimmauld]

Other than magicgui and superqt, i don't see any obvious problematic libraries pulling in shiboken2

[LordGrimmauld]

A simple-ish check is to remove the broken on shiboken2 and make the hash change for python3.13-only, then run nixpkgs-review against this PR. Actually i might try to do just that...
(obviously don't commit that XD)

[dotlambda]

Typstwriter works fine.
Linien-gui is already broken in other ways, so I'm not touching that.

Other than magicgui and superqt, i don't see any obvious problematic libraries pulling in shiboken2

Shiboken2 is only an optional dependency of superqt.
Magicgui is only used by napari, which I already fixed.

[LordGrimmauld]

Damn you work fast :)
Alright, time to give this an actual review now that there is a chance of it being complete

[LordGrimmauld]

At a glance this looks fine, but i'll wait for the build to finish.

[LordGrimmauld]

Building the 3.13 rev deps of shiboken2 (which of course all fail):

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review

---

x86_64-linux

❌ 7 packages failed to build:

• python313Packages.magicgui
• python313Packages.magicgui.dist
• python313Packages.napari-npe2
• python313Packages.napari-npe2.dist
• python313Packages.pyside2
• python313Packages.pyside2-tools
• python313Packages.shiboken2

[dotlambda]

Great, so this PR is complete.

[LordGrimmauld]

Considering nothing that attempts to use shiboken2 on python 3.13 is an application, only unused libraries, this looks fine to me.

[dotlambda]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 417345
Commit: 899493a396b127326cceb33db93345ebb932c7f1

---

x86_64-linux

✅ 7 packages built:

• kohighlights
• napari
• napari.dist
• patray
• patray.dist
• sl1-to-photon
• sl1-to-photon.dist

[pbsds]

I'll go through the full list soon. The alternative is to "soft-pin":

pythonPackages' =
    # lib.meta.availableOn does not respect meta.broken?
    if python3Packages.shiboken2.meta.available then python3Packages else python312Packages;

See #416726 for source

A hard-pin on 3.12 seems fine, shiboken2 getting 3.13 support is very unlikely. A soft-pin like this is an option, as that will then silently update python once shiboken updates.

The reason i went for a soft-pin was not because i assumed it would be fixed, but because i wanted to adhere to

• CONTRIBUTING: Add guideline to document motivation for special packaging choices #416728

Considering it's not merged yet means i don't consider it a blocker, but documenting these python312 pins would help when the time to drop python312 comes.

[dotlambda]

documenting these python312 pins would help when the time to drop python312 comes.

That makes sense and I guess git blame is not documentation enough.
I'll make sure to add comments going forward.