Python bindings HOWTO proof reader request

Ben McGinnes ben at adversary.org
Thu Mar 15 17:51:18 CET 2018


On Thu, Mar 15, 2018 at 03:50:46PM +0100, Tobias Mueller wrote:
> Hi.
> 
> On Fri, 2018-03-16 at 00:00 +1100, Ben McGinnes wrote:
> > I'd appreciate some fresh eyes proof reading it before I merge it with
> > master.  The full thing, in org-mode format,is here:
> > 
> > https://files.gnupg.net/file/data/ossmg4ung2hcpyyuks6j/PHID-FILE-
> > xgbofmytge7fzn3u5kuc/GPGMEpythonHOWTOen.org
> Cool, thanks.
> 
> Can you elaborate on this paragraph:
> 
>    Most third-party Python packages and modules are available and
>    distributed through the Python Package Installer, known as PyPI.
> 
>    Due to the nature of what these bindings are and how they work, it
>    is infeasible to install the GPGME Python bindings in the same way.
> 
> Without any further explanation I consider the argument to be weak.
> What's the nature and how is it different from all the other binary
> packages on pypi?

Fair enough, how about adding this paragraph immediately thereafter as
an explanation or clarification:

   This is because the bindings use SWIG to dynamically generate C
   bindings against =gpgme.h= and =gpgme.h= is generated at compile
   time when GPGME is built from source.  Thus to include a package in
   PyPI which actually built correctly would require either statically
   built libraries for every architecture bundled with it or a full
   implementation of C for each architecture.

By the way, each architecture there would mean *both* software
(operating system) and hardware.  So if we don't want to duplicate the
work of glibc, gcc and/or clang (and I assure you, we absolutely do
not want to do that) then we'd need to ship statically linked
precompiled binaries for Linux, BSD, OS X, Windows, Solaris, AIX,
HP-UX, HURD and other operating systems some running on any
combination of x86 (i386, i586), x86-64, 68K, RISC, SPARC, UltraSPARC
and a few other hardware types.

I dont have the hardware to cover all of those.  Do you?  I'm guessing
probably not.

Anyway, that's why these bindings don't get pushed to PyPI, because we
can't be certain that gpgme.h will build identically everywhere GPGME
is installed.  If we could be certain then it wouldn't need to be
generated from gpgme.h.in in the first place and the bindings would be
on PyPI.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180316/f54a2ef9/attachment-0001.sig>


More information about the Gnupg-devel mailing list