begging for pyme name change

[Vinay Sajip]

Dear Daniel,

>> The bindings-to-C and wrapper-over-gpg models are both useful in 


> … i'm not sure i'd reach this conclusion in the abstract.

I chose to adopt the wrapper approach because the other approach was just too hard to get working on Windows, and didn't offer all the functionality the executable did. Can we be sure that's no longer the case? Windows does seem a poor relation (for example, no separate builds of just gpgme.dll seem to be available, no support for compilation with Visual Studio toolchains, just gcc, and so on). 

> This is something for the upstream GnuPG team to wrestle with too -- how do we make it easy for people to use GnuPG in a reliable way from other programs?  It hasn't been as easy as it should be. 
For me, it's always been about ease of use across POSIX and Windows. I don't believe an endorsement by the GnuPG team of any project as the "blessed" way of interacting will be enough to swing many users over from one project to another, unless ease of use is reasonably comparable. I even use gpg 1.x in preference to gpg 2.x in some contexts because gpg 2.1 makes it harder to avoid confusing-to-the-user pinentry popups without end-users having to tweak their GnuPG configuration (there might be some way I've missed, but Googling hasn't helped). It's certainly possible for GnuPG upstream changes to make it harder to use the wrapper approach (which is why I can't easily see a way to support 2.1 properly in all respects, much as I'd like to).

> And, thanks for your ongoing work on python-gnupg

You're very welcome. I think GnuPG is a great tool to have at our disposal, and I hope that its Python story keeps on improving.

Regards,

Vinay Sajip



----- Original Message -----
From: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
To: Vinay Sajip <vinay_sajip at yahoo.co.uk>; Bernhard Reiter <bernhard at intevation.de>; "gnupg-devel at gnupg.org" <gnupg-devel at gnupg.org>
Sent: Monday, 17 October 2016, 20:40
Subject: Re: begging for pyme name change

On Mon 2016-10-17 14:31:38 -0400, Vinay Sajip wrote:

> It appears to be all about Python bindings to GPGME. However, my
> project, python-gnupg, deliberately avoids binding to any C-level
> library and instead provides a wrapper around the gpg executable.

I agree with this, but…

> The bindings-to-C and wrapper-over-gpg models are both useful in
> different contexts, and should continue to co-exist as long as
> possible.

… i'm not sure i'd reach this conclusion in the abstract.

In particular, it'd be nice to see a single clear way to use gpg in
python, so that people using python don't have to choose between one
mechanism or another.  what if they want functionality that's only
available in one mechanism, and then they *also* want functionality
that's only available in the other mechanism?  Python is supposed to
make those sorts of choices easy, and maintaining both approaches sounds
troubling for the downstreams.

This is something for the upstream GnuPG team to wrestle with too -- how
do we make it easy for people to use GnuPG in a reliable way from other
programs?  It hasn't been as easy as it should be.

> Of course the python-gpgme name is also taken (by James Henstridge's
> package - I'm not sure how maintained that is, I couldn't see any
> releases more recent than 2012 and nothing in the source repository
> newer than 2013). However, it would make more sense to see if

i think you were about to suggest asking him for that name -- i agree,
and we've already reached out to him on a different branch of this
discussion.  Thanks for the suggestion!

And, thanks for your ongoing work on python-gnupg.  It's very much
appreciated.


     --dkg