python-gssapi incompatible With Cython 3.1

[MaicoTimmerman]

With the release of Cython, the installment of python-gssapi broke on Linux systems:

  building 'gssapi.raw.misc' extension
  creating build/temp.linux-x86_64-cpython-38/gssapi/raw
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I/opt/rh/rh-python38/root/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I/opt/rh/rh-python38/root/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Igssapi/raw -I/opt/rh/rh-python38/root/usr/include/python3.8 -c gssapi/raw/misc.c -o build/temp.linux-x86_64-cpython-38/gssapi/raw/misc.o -DHAS_GSSAPI_EXT_H
  gssapi/raw/misc.c: In function ‘__pyx_pw_6gssapi_3raw_4misc_3inquire_names_for_mech’:
  gssapi/raw/misc.c:3284:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
         for (Py_ssize_t i = __pyx_nargs; i < 1; i++) {

According to Cython devs, Cython 3.1+ requires C99 compatible C compiler:
cython/cython#6861 (comment)

[jborean93]

Can you not use a C99 compatible C compiler? Is it not enabled by default in modern distros?

If not you can disable build isolation or use the PIP_CONSTRAINTS env var to constrain the Cython to the version needed.

[MaicoTimmerman]

In modern distros, yes. In our case we ran into the problem on older machines on CentOS 7, which comes with GCC 4.8.5 and uses C89/C90 by default. Build constraints help, I did not think about those and most build frontends support something like that. UV has --build-constraint, Pex uses pip, but Hatch doesn't.

Disabling build isolation is not really an option, as it would require all dependencies to have compatible build systems.

The main problem here is that a new version of Cython 3.1.0 available on Pypi broke builds. python-gssapi has to compile against Kerberos libraries, thus it cannot use wheels. However, it is not version bounding (or even better pinning) it's build-system, resulting in not have deterministic builds/installs. Any new release of Cython or setuptools can break installs.

IMO it would be best to pin the build-system dependencies, in order to guarantee deterministic builds for users.

[jborean93]

In the past this package shipped the actual cythonised .c files to avoid needing Cython when building the project. This predated PEP 517 which made it harder to guarantee that build requirements would be available. It ended up moving away and just having a version range of Cython mostly to ensure that new Python versions could work out of the box without requiring a new release of this project just with a bumped build dependency.

Now we can definitely revisit this as deterministic builds is certainly a nice goal but as you've encountered the build is also affected by the end user's system so building might change over time based on the gcc version. What is probably ideal for your use case here is to pre-compile a wheel for your host so that you don't need to compile this everytime you install the package. The benefits here are:

• you aren't subject to build requirement changes over time, basically when you decide to rebuild the wheel
• installing is a lot quicker, no need to compile the code anymore
• you don't need any dev headers during the install, only when creating the wheel for the first time

I'm going on leave and will mostly be away for a few weeks but my gut is that #360 is not the right way to go about this. We should either keep things they way they are and recommend people pin/constrain their build deps/look at pre-building wheels, or look at pinning to a specific version. I'll have to think it through and see whether pinning a version outweighs the disadvantages here.