cffi 1.15.1 install fails with python 3.12 but works with python 3.11

[samuel-riesterer-interject]

Have there been any reports on cffi issues with python 3.12?

cffi 1.15.1 works in our python 3.11 environment but does not install in a 3.12 environment with the following error:

File "D:\Users\samuelr\AppData\Local\Temp\1\tmpalrix6hq\.venv\Lib\site-packages\setuptools\msvc.py", line 190, in _msvc14_get_vc_env
  raise distutils.errors.DistutilsPlatformError("Unable to find vcvarsall.bat")

distutils.errors.DistutilsPlatformError: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/

at ~.conda\envs\pyids312\Lib\site-packages\poetry\installation\chef.py:166 in _prepare
162│
163│ error = ChefBuildError("\n\n".join(message_parts))
164│
165│ if error is not None:
→ 166│ raise error from None
167│
168│ return path
169│
170│ def _prepare_sdist(self, archive: Path, destination: Path | None = None) -> Path:

Note: This error originates from the build backend, and is likely not a problem with poetry but with cffi (1.15.1) not supporting PEP 517 builds. You can verify this by running 'pip wheel --no-cache-dir --use-p
ep517 "cffi (==1.15.1)"'

I know the error is "unable to find vcvarsall.bat" but why this works in 3.11 and not in 3.12 I don't know.

[mattip]

What visual studio do you have on the machine?

If I had to guess, I would imagine it is something like

• there are wheels for python 3.11 so you don't have to build in order to install cffi
• there is not a wheel for python 3.12 for that version of cffi, so you have to build from source
• your version of Visual Studio does not play well with setuptools

Is there a reason you cannot use 1.16 which has wheels for python3.12 + windows?

[samuel-riesterer-interject]

Ok I think this is it, I will reach out to my team to update to 1.16.0

[nitzmahone]

3.12 support was only added in 1.16, which is also the first release where cffi started declaring a minimum Python X.Y version in the packaging metadata (3.8 as of this writing). I'm on the fence about adding a maximum Python version to prevent this class of problem in the future, but given the way I've seen most projects referencing CFFI with no dep version pins at all and no minimum Python version for their own project, it's probably not a terrible idea, especially as newer Python releases get more aggressive with breaking C API changes. It's probably better to soft-fail at install-time on an untested Python X.Y version and/or do a tiny dot release to bump that once we know it actually works than to fail deeper in the build in much more difficult to diagnose ways...

[nitzmahone]

I've opened #37 to consider actually declaring a maximum supported Python version for any given CFFI release; closing this issue since it seems like OP's issue will be solved by moving to a supported CFFI release.