Python bindings HOWTO proof reader request
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:
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the Gnupg-devel