Install cffi with Homebrew, apt

Project links

• Homepage

Commands and aliases

• cffi-gen-src

Project history

The official documentation credits Armin Rigo and Maciej Fijalkowski and describes a design influenced by LuaJIT's FFI: users should mainly need to know C and Python, keep Python-related logic in Python, and choose between ABI-level and API-level access depending on portability and build needs.

PyPI lists the first cffi release, 0.1, on 2012-06-18. The 1.0.0 series in 2015 introduced the out-of-line generation model that became central to packaging CFFI-based wrappers with setuptools. Later releases continued to track newer CPython versions, PyPy use, wheels, platform support, and Python packaging changes.

Adoption history

CFFI became especially important in PyPy culture because the official installation notes describe it as distributed with PyPy and as the recommended way to interface with C libraries there. On CPython, it is common in packages that need C library access without maintaining a large handwritten extension layer.

The package's official PyPI page shows sustained maintenance across many releases from 2012 through 2026, with current wheels for major CPython versions and platforms. Homebrew packages it because command-line and build workflows sometimes need the project tooling alongside Python package-manager installs.

How it is used

Typical usage starts with `from cffi import FFI`, a `cdef()` block copied or adapted from C declarations, and either `ffi.dlopen()` for ABI mode or `ffibuilder.set_source()` plus compilation for API mode. The official overview presents both in-line and out-of-line modes and recommends API mode when a C compiler is available.

CFFI is used to wrap existing shared libraries, compile small C wrapper modules, allocate C data from Python, pass buffers and structs, call function pointers, and expose Python functions to embedded interpreters.

Why package nerds care

CFFI is package-nerd significant because it changed the shape of Python native-library packaging: projects can describe a C interface in Python and let the build backend generate extension glue, instead of carrying a large CPython C API surface.

It is also a useful marker for interpreter-portable native bindings. Package maintainers care about whether a project uses CFFI because it affects wheels, build dependencies, PyPy compatibility, libffi availability, and whether downstream systems need compiler toolchains.

Timeline

• 2012: PyPI lists cffi 0.1 as released on 2012-06-18.
• 2015: cffi 1.0.0 introduced out-of-line module generation.
• 2020: cffi 1.14.1 release notes say source hosting moved to Heptapod.
• 2025: PyPI lists cffi 2.0.0 as released on 2025-09-08.
• 2026: PyPI lists cffi 2.1.0 as released on 2026-07-06.

Related projects

• CFFI is discussed by its docs alongside LuaJIT FFI, ctypes, Cython, SWIG, CPython native C extensions, PyPy, pycparser, and libffi.

Sources

• https://cffi.readthedocs.io/en/latest/whatsnew.html
• https://cffi.readthedocs.io/en/stable/
• https://cffi.readthedocs.io/en/stable/goals.html
• https://cffi.readthedocs.io/en/stable/installation.html
• https://cffi.readthedocs.io/en/stable/overview.html
• https://github.com/python-cffi/cffi
• https://pypi.org/project/cffi/