Consider adding upper bound packaging metadata

[nitzmahone]

The way typical projects seem to refererence CFFI with no (or only lower-bound) version pins and/or Python version bounds, we're likely to only see more issues like #33. We added lower-bound python_requires to match CI testing/wheels in 1.16.0 to keep folks in this situation working on older Pythons...

Given CFFI's extremely tight coupling to CPython's APIs (often including unstable/internal), and the accelerating pace of breaking changes to Python's C API, it seems like adding an upper bound X.Y to python_requires would be prudent to trigger clear "soft failures" at dep install/build time due to unsupported Python versions, rather than the difficult to diagnose issues that are almost certain to occur deeper at code-gen/build/runtime when using CFFI with a "too new" Python version. On the off-chance that a new Python X.Y release "just works" with an existing CFFI version, it's much easier for us to just do a tiny dot release that bumps the upper bound than for every user of every project to diagnose the likely problems stemming from their own naive upper bound CFFI pins without a corresponding Python version environment marker.

We may need to consider doing the same for setuptools, at least in the actual packaged bits (providing a "known working" tested range in packaging metadata instead of just a minimum) as that project also continues to more aggressively deprecate and remove old functionality. It seems like most end-users are ignorant of the underlying issues, so since CFFI shows up during the build failures, it must be our fault. 😉

[arigo]

+1, agree with your reasoning. For me, I'd much prefer a clean dependency failure of setuptools instead of a message that means "you need a C compiler to do that" in a very obscure way, or a C compiler error if people try to compile old versions of CFFI without the proper fixes for the newer versions of CPython. People that really want to bypass that check can do so anyway, for example by deleting the line in setup.py or whatever the installer-du-your is.