proposal python-gnupg2 (was: begging for pyme name change)

[Vinay Sajip]

Dear Bernhard,

> I believe the goal our GnuPG-Initiative is to add all needed functionality to gpgme. It basically is a wrapper around calling gpg(.exe).

I had no idea that was the case, if I understand you correctly. I had assumed that gpgme was a lower-level library providing the basic crypto functionality, using common code used by gpg(.exe). If gpg(.exe) is the canonical foundation which everything else depends on, then where is the benefit of a Python binding over a C wrapper over gpg(.exe)? Python provides a reasonably good mechanism for interacting with subprocesses. I've probably misunderstood what you said, so please tell me if I have!

Regards,

Vinay Sajip


----- Original Message -----
From: Bernhard Reiter <bernhard at intevation.de>
To: gnupg-devel at gnupg.org; Vinay Sajip <vinay_sajip at yahoo.co.uk>
Cc: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
Sent: Tuesday, 18 October 2016, 7:57
Subject: proposal python-gnupg2 (was: begging for pyme name change)

Hi Daniel, Hi Vinay,

Am Montag 17 Oktober 2016 18:45:27 schrieb Daniel Kahn Gillmor:
> I hear you, but let's be clear that Vinay Sajip was maintaining this
> wrapper long before the GnuPG upstream team decided to offer any sort of
> python functionality at all.

to me it is not a timing issue, but how to offer the best GnuPG usage
experience (for developers). (Gpgme used to be around for a while by now.)

> And this other project has an existing userbase that would be good
> to reach out to, rather than to ignore.

Yes, thanks for bringing Vinay into the discussion.
And thank you Vinay for your contribution to Free Software and
GnuPG!

> It's not clear to me how to break this logjam, even if we
> manage to get all parties in agreement that there should be a single
> preferred pythonic interface to GnuPG.

There may be different libraries in the future of course, but it would be 
helpful if we have one that is considered "standard". And if we can pool
most of our efforts in improving this standard module to be well tested
and offering all functionality. This is why I suggest using the most natural 
name. My suggestion to solve this is to use the new name with the major
version number being increasted like "python-gnupg2".
(Though it still helps to access GnuPG 1.4.x executables.)

> > The brand recognition is specifically highest about "gnupg" not "gpg".
>
> I have no idea whether this is true or not.  How are you measuring it?

My observation over a couple of years. Feedback from people that get exposed
to OpenPGP. I'll followup on this with an extra post.

As for the perceived shortcomings of gpgme: I believe the goal our 
GnuPG-Initiative is to add all needed functionality to gpgme. It basically
is a wrapper around calling gpg(.exe). Some features are less known
other have been added but overall it is the best solution for most cases, see 
Andre's talk from https://openpgp-conf.org/program.html .


Best Regards,

Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner