python bindings for gpgme

[Ben McGinnes]

On Wed, Jun 01, 2016 at 02:38:29PM +0200, Bernhard Reiter wrote:
> Am Mittwoch, 1. Juni 2016 13:44:58 schrieb Ben McGinnes:
>> On Wed, Jun 01, 2016 at 12:37:05PM +0200, Werner Koch wrote:
>>> On Wed,  1 Jun 2016 09:38, bernhard at intevation.de said:
>>>> Why did you choose porting pyme over pygpgme?
>>>
>>> Ben has been working on this for more than a year (see
>>> https://git.gnupg.org/gpgme.git) and explained his work on
>>> gnupg-devel.  Challenging this decision now does not seem to be
>>> very helpful.
> 
> I saw the explanation last May, there has not been much discussion
> since then. And frankly I did not fully realize back then, that you
> would want this to be the official gpgme python api. I realize I am
> being late, but it is as early as I understood the potential
> implications. Maybe pyme is the better choice, I don't know. I
> haven't seen the decision documented anywhere, though.

I don't actually see pyme as the ideal for the official Python API
component, that's what the plans around a CFFI based solution are for.
One which would be able to behave pythonically, of course, but more
importantly would be able to be accessed by any other language
(e.g. on a unix socket locally) in order toprovide GPGME access to all
those other languages.  One of the other decisions made around that
was to support JSON data formats for interacting with the thing
because far too many people automatically think REST when they hear
API (even though this could *never* actually be a REST API.

In the meantime I do think that pyme is a reasonable interim solution
and certainly better than the most popular (and easiest) method of
accessing GPG in Python: the python-gnupg module.  Which is basically
just calling GPG commands in subprocess.call() functions.

>> I went back and had another look at pygpgme to see why I didn't choose
>> that route.  I was reminded very quickly why: it doesn't compile so
>> well on OS X or, indeed, at all.  I'd have to rewrite bits of it to a
>> much greater extent. 
> 
> That is something that could have been potentially fixed, if the
> mapping to python were better. (Which I don't know at this point.)

I'm pretty sure it begins with stupid assumptions like hard-coding
where certain libraries will always be.  Whereas the pyme port to
Python 3 behaves identically to the original Python 2 versiom with the
exception of the GTK 2 based examples, since the GTK 2 support has not
been carried over to Python 3 (it has GTK 3 support instead).

>> Plus from the PyPI view it looks a bit abandoned 
>> (that may not actually be the case, but the version on PyPI hasn't
>> been updated in four years.
> 
> Both pyme and pygpgme did not see much of maintenance work if I
> remember correctly. I think that the 0.3 release of pygpgme in 2012
> possibly is the newest larger update to both libraries.

Well, last year one hadn't been updated in 3 years and the other had
been updated around a year prior.  Plus it worked in Python 2 and I
was initially looking for something that would let me move a whole
bunch of other things off Python 2.

>> Oh, there is a port for it on MacPorts which might work, but it's
>> Python 2.7 only, so nope.
> 
> python3-gpgme packages on Debian and Ubuntu show that python3
> support should be close.

The setup.py file says it should support Python 3, but the fact that
that's not included in any of the MacPorts ports indicates that I may
not be the only person who had trouble installing from source.

As it happens the Python 2 port didn't install either, but for rather
different reasons (it views GPG 2.1 as a conflict which precludes
GPGME being installed, even though I overrode that).


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: </pipermail/attachments/20160602/b9f97df3/attachment.sig>