[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2193: pyOpenSSL 0.14 pulls in a bunch of new dependencies

[Tahoe-LAFS]

#2193: pyOpenSSL 0.14 pulls in a bunch of new dependencies
-------------------------+-------------------------------------------------
     Reporter:  daira    |      Owner:
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  undecided
    Component:           |    Version:  1.10.0
  packaging              |   Keywords:  packaging setuptools pyopenssl
   Resolution:           |  cryptography six cffi pycparser
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by glyph):

 Replying to [comment:14 daira]:
 > In any case, I guess we have no choice but to add `cffi` as another
 binary dependency. (The pure Python dependencies aren't so much a
 problem.) Sigh.

 While I understand that the task of adding `cffi` itself is yet more
 frustrating package churn, there are a number of reasons to be
 enthusiastic about it:

   1. Writing `cffi` modules is far easier, safer, etc, than writing any
 other kind of extension module.  Unless you've used it, it's hard to
 explain just ''how much'' easier and safer it is, but one personal
 anecdote I can give you is that I once spent about 20 hours wrapping a
 fairly complex C library with cffi, including callbacks, reentrancy, and
 pointer math, and literally experienced ''zero'' segfaults in the process.
 One segfault I had near the end turned out to be a bug in the C library
 itself and not a problem with my extension.
   2. `cffi` modules are JIT-visible in PyPy and will therefore actually
 speed up applications on PyPy, unlike `cpyext`-built extensions, which
 generally have enough overhead that they slow things down.
   3. the `cffi` team provides packaging and building tools for extension
 modules to normalize the process of distributing binary dependencies, in a
 way which is challenging to do for arbitrary extension modules, and (in
 combination with the PyPA developers) is working on more.  This has been
 somewhat rocky to get off the ground, but once the binary compatibility
 story for wheels has been worked out for OS X and Linux, this kind of
 uproar from users when a binary dependency is added should get ''much''
 rarer, because they'll actually be able to install them from PyPI and have
 them actually work without a C compiler.
   4. Jython developers are working on a cffi runtime support system now as
 well, making it by far the most portable way to distribute an extension
 module; a number of "it only works on CPython because of a C dependency
 that doesn't work on any other VMs" projects will be able to migrate to
 other interesting environments.

 Finally, there's a `ctypes` backend for `cffi`; I'm not sure how complete
 it is, but in principle it ought to allow for (slow) invocation of
 arbitrary cffi-based extensions with no C compiler installed.  If Tahoe
 still has users having problems before The Great Packaging Singularity
 Where Everything Finally Starts Working, it might be worthwhile to figure
 out if this can be enabled for your users somehow if their C compiler
 isn't installed or doesn't work.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193#comment:16>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage