python-afs: Compatibility with Python 3.13

Python 3.13 introduces a header <lock.h>, which conflicts with OpenAFS's
identically-named header. Python 3.15 will probably rename it to
pylock.h[1], but it's here for Python 3.13 and probably Python 3.14[2].

In the interim, force OpenAFS's headers to come before Python's when
building python-afs. This is a little tricky, because Python's headers
use -I by default while OpenAFS's use -isystem, and -I headers all come
before -isystem ones. However, if we add Python headers with -isystem at
the start of the compiler command, Python's -I will be treated as a dup
of a system header, and Python's headers will be moved to the system
section of the search path. *However*, because they're at the *start* of
the search path, they'll still beat OpenAFS, so we need to also add
-isystem for OpenAFS at the start of the compiler command, so the
relative order among the system section is correct.

Upstream mit-athena/python-afs has an issue for this[3], but because Nix
builds weirdly, the patch I wrote there doesn't work for Nix.

[1] python/cpython#136759
[2] python/cpython#137075 (comment)
[3] mit-athena/python-afs#6

Author: dehnert

pkgs/python-afs.nix

@@ -1,5 +1,5 @@
 { stdenv, pkgs, lib, fetchFromGitHub,
-  cython, buildPythonPackage, setuptools,
+  cython, python, buildPythonPackage, setuptools,
   openafs, libkrb5,
 }:
 
@@ -34,6 +34,27 @@ in buildPythonPackage {
     "afs"
   ];
 
+  env = lib.optionalAttrs (python.pythonAtLeast "3.13") {
+    # Workaround for https://github.com/mit-athena/python-afs/issues/6
+    # Can probably be removed in 3.15 or maybe 3.14
+
+    # Without this hack, Python and OpenAFS have competing lock.h files, and we
+    # need OpenAFS's to win but Python's does win. Until Python 3.15 comes out,
+    # we force OpenAFS's headers to come before Python's when building
+    # python-afs. This is a little tricky, because Python's headers use -I by
+    # default while OpenAFS's use -isystem, and -I headers all come before
+    # -isystem ones. However, if we add Python headers with -isystem at the
+    # start of the compiler command, Python's -I will be treated as a dup of a
+    # system header, and Python's headers will be moved to the system section
+    # of the search path. *However*, because they're at the *start* of the
+    # search path, they'll still beat OpenAFS, so we need to also add -isystem
+    # for OpenAFS at the start of the compiler command, so the relative order
+    # among the system section is correct.
+
+    NIX_CFLAGS_COMPILE="-isystem${openafs.dev}/include -isystem${python}/include/python${python.pythonVersion}";
+    #NIX_DEBUG="1";
+  };
+
   # The tests assume that we have AFS installed and working on the machine
   # (e.g., they access files in AFS, expect ThisCell to be set, etc.), so
   # skip them.