begging for pyme name change

[Daniel Kahn Gillmor]

[ 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161017/ce97dbc6/attachment.sig>