ENH: Rename gnupg to gpg.

[pelson]

This is a highly speculative PR that attempts to rename the high-level importable gnupg to gpg in an attempt to address #47. I'm not trying to be abrasive - this is a sincere attempt at exploring the renaming space. I definitely will have missed some small details in this PR, and subsequent work is highly likely, however, with this change I'm able to install python-gnupg and gnupg side-by-side:

> pip install python-gnupg
Collecting python-gnupg
  Using cached python_gnupg-0.4.1-py2.py3-none-any.whl
Installing collected packages: python-gnupg
  Installing from a newer Wheel-Version (1.1)
Successfully installed python-gnupg-0.4.1

> python
Python 3.6.1 | packaged by conda-forge | (default, May 23 2017, 14:31:56) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gnupg
>>> gnupg.__version__
'0.4.1'
>>> import gpg
>>> gpg.__version__
'2.3.0-2-g1db1ccf-dirty'
>>> gpg.__authors__
{'lovecruft_isis': <Storage {'name': 'Isis Agora Lovecruft', 'contact': 'isis@leap.se', 'public_key': '0xA3ADB67A2CDB8B35'}>, 'sajip_vinay': <Storage {'name': 'Vinay Sajip', 'contact': 'vinay.sajip@gmail.com', 'public_key': '0xDE6EF0B2'}>, 'traugott_steve': <Storage {'name': 'Steve Traugott', 'contact': 'stevegt@terraluna.org', 'public_key': None}>, 'kuchling_am': <Storage {'name': 'A.M. Kuchling', 'contact': 'amk@amk.ca', 'public_key': None}>}

I'm keen to avoid this PR sitting in the repository idly - @isislovecruft I strongly support either merging it or closing it (either is completely fine with me).

[ankostis]

But why gpg and not gnupg_ng as Debian has done (see #47)?

[pelson]

@ankostis - the name itself I don't have any opinion on. The key for me was to have any different name. Notice that, as I understand it, https://github.com/isislovecruft/python-gnupg/issues/47#issuecomment-282588942 didn't actually come to a conclusion about the imported name, only the name of the package to be installed (i.e. apt-get install python-gnupg-ng). This PR changes the import name.

[ankostis]

There are at least 5 names, and the situation is the following (please correct me where I'm wrong):

1. import-name:
   • old-project: gnupg,
   • this-project: gnupg,
   • this-PR: gpg
2. pip-package:
   • old-project: python-gnupg,
   • this-project: gnupg,
   • this-PR: gpg
3. distro-names:
   • old-project: python-gnupg & python3-gnupg,
   • this-project[1]: python-gnupg-ng,
   • this-PR: ??
4. GitHub/BitBucket project:
   • old-project: https://bitbucket.org/vinay.sajip/python-gnupg
   • this-project: https://github.com/isislovecruft/python-gnupg
5. Docs url:
   • old-project: https://pythonhosted.org/python-gnupg/
   • this-project: ??

I suggest to add a "header" in the README listing the current names in usage for for all above cases (see our project for example).

Regarding this PR, my preference would be to use gnupg-ng for the import package and python-gnupg-ng for the PyPi-package & distro-package,

• bc it conveys the relationship and momentum of this project against the old one,
• and is compatiblwe with Debian distro name.
• Also python-gnupg is already contained in the GitHub url, so either keep it (or even better, move it)
• Finally, shrinking the name to gpg, which happens to be the name of the main command-line tool of the "GNU Privcay Guard" project, drops important information about this project and it's relying native-library.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754120

[Hasimir]

Why perform a name change to solve one naming conflict if the result will only create another naming conflict? It's just that instead of having a naming conflict with the project this one forked from you're going for a conflict with the actual parent project, you know, the one you're wrapping.

Case in point, I don't have this project installed, but I do have this:

Python 3.7.0 (default, Jun 29 2018, 13:09:59)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gnupg
>>> import gpg
>>> gnupg.__version__
'0.4.1'
>>> gpg.__version__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'gpg' has no attribute '__version__'
>>> gpg.version.versionstr
'1.11.2-beta89'
>>>

The Python bindings for the GPGME API import as gpg for the module name. Creating a situation where you would be squatting both the project forked from and the GNU Privacy Guard itself is pushing deeply into uncool territory.

[pelson]

I'm keen to avoid this PR sitting in the repository idly

Given the uptake, I'll close.