begging for pyme name change

[Uri Blumenthal]

One quick point: as far as I know, the highest "brand recognition" today is gpg, probably followed by PGP (at least among those who remember :)), gnupg being a distant third. 

And I've been with PGP development since its inception. 

Sent from my iPad

> On Oct 17, 2016, at 12:47, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> [ 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
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel