Python bindings HOWTO proof reader request
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Mar 19 09:11:09 CET 2018
On Mon 2018-03-19 14:35:02 +1100, Ben McGinnes wrote:
>> A quick comparison of "gpg" and "build-essential" on Debian's popcon
>> seems to indicate that it's much easier to bring gpgme to user's
>> machines if there was a binary package on PyPI.
> Ah, yes, the Debian ecosystem ... I have a slightly different plan
> there, but that essentially boils down to convincing dkg to make sure
> GPGME ships with future Debian releases in whole with the relevant
> language bindings (specifically the Python bondings and the C++/Qt
> bindings) should open that up quite nicely. With its inevitable
> flow-on effect with Debian-based distros.
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.
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:
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
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).
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the Gnupg-devel