Python bindings HOWTO proof reader request

[Ben McGinnes]

On Mon, Mar 19, 2018 at 08:11:09AM +0000, Daniel Kahn Gillmor wrote:
> On Mon 2018-03-19 14:35:02 +1100, Ben McGinnes wrote:
> 
> I believe debian *does* currently ship gpgme's python bindings
> (python-gpg and python3-gpg) and C++ (libgpgmepp6) and Qt
> (libqgpgme7) bindings (and their development headers:
> libgpgmepp-dev) already.  If that's not the case, please explain
> what you need in more detail, i'd like to fix it.

Cool, I generally don't use Debian (or RHEL/CentOS) so I wasn't sure
on that.  My Linux history tended more towards Slackware.  In fact
it's been pretty much Slackware and Solaris since the '90s (yeah, I
know, but that's how I ended up at Sun in the first place).

> One gap that still does exist is that gpgme's source is only willing
> to build against one version of python3 at once, which greatly
> complicates python transitions for packages that depend on
> python-gpg:
> 
>     https://dev.gnupg.org/T3354

Ah, that.

> If you'd be willing to reconsider that decision and make it
> straightforward to build gpgme python bindings against multiple
> versions of python3 at once, that would make python3-gpg fit much
> better in the debian ecosystem.

Part of the problem is the M4 code in configure.ac is already pretty
hacky as it is.  Originally it would only find the first two of each
major branch it found and that's since been updated to find the latest
release of each major release (i.e. python and python3) in the $PATH
at the time GPGME is compiled.  The M4 code then calls the relevant
Python executables with "setup.py install" to install to
site-packages.

We may be able to adjust this to check for other versions explicitly
and also install for those versions.

> Alternately, a pure-python version (using either ctypes or cffi) might
> be easier to maintain and distribute, requiring the user to "only" fetch
> the gpgme shared library (and the binaries it ultimately invokes, like
> gpg, gpgsm, and their associated components like gpg-agent, etc).

That is my long term plan: to (ideally) port the damned thing off SWIG
entirely and to CFFI.

Ctypes are pretty much out since that would result in not only a
difficult migration, but also a difficult maintenance path.  If you
want to see how difficult, have a look at vlc.py which uses ctypes to
link to libvlc.  It works, but not without some seriously broken bits
and it doesn't handle differing release versions at all well (yeah, I
contributed a little there too a few years ago and it was a bit
migraine inducing).

CFFI, on the other hand, has lots of advantageous aspects.  Not least
of which being that once done it would open up a lot more in the way
of platform support, including PyPy and comparable reach to
cryptography.py (possibly also to PyCryptodome, the successor to
PyCrypto).

The problem with CFFI, however, is that it doesn't quite cover all the
features of C99 yet and some of the features it doesn't cover are in
gpgme.h.

There may be ways around these drawbacks to still get it to play
nicely, but I'm still researching that.  The other possibility is
seeing what it takes to get the C parser that CFFI uses updated to
cover all of C99, but again I'm not a hundred percent sure what that
requires either.

So far efforts to convince certain Google engineers to do it haven't
worked, but who knows?  ;)

> but i don't want to make any claims about how easy it would be to
> make that kind of transition while maintaining a stable python API.
> i suspect it would not be easy.

You suspect correctly.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180320/349435b3/attachment-0001.sig>