Distribute the CFFI ring implementation in the wheels? about persistent HOT 5 CLOSED

Full disclosure: I'm using the Ring implementation in RelStorage (I know it's documented as not for external use---I wrote those docs :) and the CFFIRing is much faster than the DequeRing on CPython. It would be nice to piggyback on the existing Appveyor setup and such of persistent so that I don't have to set all that up for RelStorage and can keep uploading just a single universal wheel.

from persistent.

Importing the module-to-be-installed in setup.py feels icky to me. Can we use something from @dstufft's CFFI blog post?

Also, for Windows PyPy users, why would they want the CFFI ring, if the deque version is only faster for CPython?

from persistent.

On Aug 10, 2016, at 12:27, Tres Seaver [email protected] wrote:

Importing the module-to-be-installed in setup.py feels icky to me. Can we use something from @dstufft's CFFI blog post?

I agree it's ugly. But it's the only way to work with older CFFI versions, like the version shipped with PyPy on Travis. To use the cffi_modules keyword you need at least PyPy 2.6 IIRC. I went through the same pain for gevent.

from persistent.

On Aug 10, 2016, at 12:27, Tres Seaver [email protected] wrote:

Also, for Windows PyPy users, why would they want the CFFI ring, if the deque version is only faster for CPython?

The CFFI ring is faster than the deque ring everywhere, as far as I can remember. But currently PyPy windows users (or CPython users that define PURE_PYTHON, for that matter) will get the deque ring unless they're set up to compile extension modules.

But that only matters for users of the pure-python persistent implementation, because the C implementation includes its own ring (that the CFFI implementation uses).

from persistent.

In zodb/relstorage#128, I realized it was possible to support both the old and new style of CFFI building at the same time. And then, when I needed features that PyPy 2.5 doesn't support, I realized that (a) nobody is using PyPy 2.5, given the current version is 5.4 and much faster; and (b) it's pretty trivial and doesn't hurt Travis test times to install an updated PyPy on Travis.

So we could do that and it might be a good thing.

But my own need for this has gone away. See #45.

from persistent.