* At some point, as mentioned in an earlier commit, we should actually make
some sort of helper function for adding extra keyring, so that their keys
can be used/imported/exported/whatever the user wants to do with them,
without changing the normal main keyrings.
* To import, the same 'import gnupg; gpg=gnupg.GPG' is still used, so this
changes nothing for applications which have started using this fork.
* This name appears to be untaken on PyPI, the changes I've made thus far are
significant, and, I believe, are not entirely backwards compatible with
upstream, do to various keyword argument and method renamings and such.
* Upstream is unresponsive, their development is private, and the only way to
get their code is to download an entire tarball and do a diff, since no
public CVS is available. Also, looking at their recent releases in the past
five months, they appear to be fixing bugs I've already fixed, albeit in
different ways -- and not all of the bugs I've fixed, as the shell escape
trick still works in upstream's 0.3.4 version -- which leads me to believe
that they are generally oblivious to this fork, though I have tried to
contact them several times.
* At first, I merely bumped the major version number up to indicate the
incompatibility, but in order to upload to PyPI it would need a different
name, and so I might as well pick a new one and just go with it, in order
to avoid the general confusion which might result from keeping the name
'python-gnupg'.
* Change the returned _parsers.GenKey from gnupg.GPG.gen_key() to store the
location of the renamed temporary keyrings as attributes. This way, one can
do something like:
>>> key = gpg.gen_key(key_input)
>>> key.keyring
'./generated-keys/328A5C6C1B2F0891125ECBE4624276B5A2296478.pubring.gpg'
Isis Lovecruft
Tom Galloway