Problems with pip install gpg

Bjarni Runar Einarsson bre at
Tue Dec 27 00:49:44 CET 2016

Hash: SHA1

An update:

I have looked into this in more detail.

It appears that this is not easily solvable due to the modularity
of the GnuPG codebase; it's not really reasonable to ship all the
GnuPG modules as part of the Python "source package" and I
haven't found much precedent for Python modules actually
downloading additional dependencies during their build phases.

I thought they did (as stated in my original message), but it
turns out all they download is the Python source package and
other *Python* dependencies. External dependencies appear to be
out of scope for the pip tool. I am going to ask around a bit
more, but this is my current understanding.

AFAICT, this leaves two options:

1) Publish static binaries.

2) Make the wrappers backwards compatible.

Details on both options:

Publishing static binaries (note: imprecise terminology, sorry)
would involve changing the build process for the Python wrapper
to directly link all the dependencies into the SWIG-generated
shared object, and then publishing Python binary "wheels."

This is probably a relatively straightforward change to the build
process, but it implies the GnuPG team would start directly
publishing binaries. I think this would be a significant
departure from what the team has done until now, and would
probably require some sort of build farm for the different
distros. A bit much work?

The other option, making the wrapper backwards compatible, so you
can download the latest wrapper from pip, but build it against
whatever older version of libgpgme your distribution is currently
shipping, would elegantly solve the Linux use-case and let people
start getting into the habit of using "pip install gpg" today.
They wouldn't have access to all the features, but it could still
be a significant step towards defragmenting the Python/GnuPG

I don't know how much work this is, since the wrapper is
auto-generated using SWIG and I'm not familiar with that tool.
But I suspect this is the easier of the two options, if the GnuPG
team wants to make their PIP package useful in the near future.

Note that because of the lag time between when GnuPG upstream
releases new things and the distributions catching up and
publishing updates, I don't think this problem is going to go
away unless a specific effort is made.

Hope this helps,
 - Bjarni

Version: GnuPG v1


More information about the Gnupg-devel mailing list