Victor Stinner schrieb am 02.02.22 um 11:35:
I wish that there would be a 3rd option: ship C code generated by Cython *but* run Cython if this C code "looks" outdated, for example if building the C code fails with a compiler error.
So, one thing I did yesterday was to make sure that .c files get regenerated when a different Cython version is used at build time than what was used to generate them originally. Thinking about this some more now, I'm no longer sure that this is really a good idea, because it can lead to "random" build failures when a package does not pin its Cython version and a newer (or, probably worse, older) one happens to be installed at build time. Not sure how to best deal with this. I'm open to suggestions, although this might be the wrong forum. Let's discuss it in a ticket: https://github.com/cython/cython/issues/4611 Note that what you propose sounds more like a setuptools feature than a Cython feature, though.
So people using stable Python versions like Python 3.10 would not need Cython, but people testing the "next Python" (Python 3.11) would not have to manually removed generated C code.
That sounds like an environment variable might help? I don't really want to add something like a "last supported CPython version". There is no guarantee that the code breaks between CPython versions, so that would just introduce an artificial support blocker.
In Fedora RPM packages of Python projects, we have to force manually running Cython. For example, the numpy package does: "rm PKG-INFO" with the comment: "Force re-cythonization (ifed for PKG-INFO presence in setup.py)". https://src.fedoraproject.org/rpms/numpy/blob/rawhide/f/numpy.spec#_107
In my pythonci project, I use a worse hack, I search for generated C files and remove them manually with this shell command:
rm -f -v $(grep -rl '/\* Generated by Cython') PKG-INFO
This command searchs for the pattern "/* Generated by Cython".
Right. Hacks like these are just awful. There must be a better way. Stefan