[pypy-dev] curses_cffi and others

[Gabriel de Perthuis]

> Hi all, hi Jeremy,
> 
> I'm thinking about merging the curses_cffi branch, and I see efforts
> going on in sqlite-cffi.  Great :-)
> 
> We need to think about how we want to support cffi-based modules in
> PyPy.  So far the idea is to include the official release of CFFI
> together with regular PyPy installations.  Then, how can we disable
> "pip install cffi" from breaking everything up by installing a
> different release of cffi on top of PyPy?  Is it enough to detect in
> cffi's setup.py "oh, it's PyPy and cffi is already installed, so I'll
> do nothing"?  Should it still check that the version number matches,
> and complain if it doesn't?

Hello,
Packages using CFFI should be able to install-require CFFI whatever the
interpreter is, including requiring newer versions than the one the interpreter
ships. (I can't require users of my packages to install a newer interpreter,
or wait for a given CFFI version to land in a CPython release, whereas setup
requirements basically come for free).

Giving the embedded copy a different name should prevent most kinds of
interference (it's the way Django, requests, etc use). So call the embedded
CFFI something like cffi_embedded. That way a project can require a newer CFFI
from PyPI without the two of them interfering. _cffi_backend (the one with
special interpreter support on PyPy) can be shared between both copies, but
it's smaller and easier to maintain compatibility.

Incidentally, trying to share an import name between two packages can't
be done reliably (setuptools used to do some path hacks to put eggs earlier
in the import path, but they were fragile and broke with virtualenv; plain
distutils doesn't have those hacks). Explicitly selecting implementations
with `import as` and an ImportError clause is much more predictable.