begging for pyme name change

[Vinay Sajip]

Dear Daniel,

Thanks for bringing this discussion to my attention. 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. There are some benefits which flow from this:

1. The C-level library's functionality (as documented) seems to lag somewhat behind the functionality expressed in the gpg executable - at least, it did at the time when I looked for a binding I could use. There also seems to be very little documentation about building from source on Windows - for example, the page https://www.gnupg.org/documentation/manuals/gpgme/ seems to have no reference to Windows whatsoever.
2. The gpgme functionality on Windows seems to revolve aroung gpg4win, which seems to be a UI-heavy package which (it appears) needs to be installed separately on Windows machines and is hard to integrate into other applications (especially for back-end, server applications where UI is not a consideration). On the other hand, deploying other applications with the gpg executable is trivially easy on Windows - just copy gpg.exe and a couple of i18n DLLs to a location on the path, and python-gnupg is operational. No need to worry about DLL versioning, different incompatible MS libc-level runtimes, etc.

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. Note that the python-gnupg name is also used by Debian and Fedora for their distro adaptations of my package, which of course then feeds through into a lot of derived distros such as Ubuntu, Mint and so on. Both OpenBSD and FreeBSD package my project as py-gnupg.

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 


However, the wording suggested by Bernhard - "If you want GnuPG's quality for crypto from python, use its python module." glosses over the distinction, whereas "binding" makes it seem more closely associated with the C library. On a side note, it also seems to impute lower quality to other modules, which I'm not sure is entirely fair ;-)

Regards,

Vinay Sajip



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

[ adding Vinay Sajip to this e-mail thread, so he knows this is under
  discussion; Vinay, if you haven't been following this discussion about
  the various python/gnupg namespace issues, you can see the start of
  the discussion over at
  https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031810.html ]

On Mon 2016-10-17 03:51:27 -0400, Bernhard Reiter wrote:
> https://bitbucket.org/vinay.sajip/gnupg is not the official python GnuPG API
> and "gnupg" is **our** namespace so to say. (Still any Free Software 
> contribution is nice, so it is cool that this module was written and 
> published. On the other hand, if we try to raise adoption for GnuPG, we all 
> have a strong interest that there is recognition about what is more or less 
> maintained.) IMO "python-gnupg" is the best name for this.

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.

I think the fact that upstream is now aiming to take responsibility for
a python binding to GnuPG is great; but we can't ignore the fact that
this other project was out there filling this need long before upstream
was.  And this other project has an existing userbase that would be good
to reach out to, rather than to ignore.

> If there are conflicts any distribution could solve them by version numbers
> when in doubt. Maybe debian would use package names like
>
>    python3-gnupg2
>    python-gnupg2
>
> To show that the there was an incompatible API change.
>
> My guiding principle is: what name would developers expect when looking
> for the GnuPG API?

right, and the lack of declared upstream support has left this vacuum
where the existing multiplicity of projects are all (confusingly)
available.  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.

> 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?

> So the connection is: If you want GnuPG's quality for crypto from python,
> use its python module.

I agree that this phrasing is probably better than the term "binding",
thanks.

        --dkg