Python bindings HOWTO proof reader request

[Daniel Kahn Gillmor]

On Sat 2018-03-24 09:01:51 +1100, Ben McGinnes wrote:
> Also, I do view this type of binary release as essentially an
> additional amount of work which is only made necessary by the
> deliberate actions of third parties to break functionality.  That is,
> it is only necessary because distribution managers have manually
> removed the bindings from the library in the first place or simply not
> updated the versions of the libraries they bundle with their
> distribution in the first place.  In some cases both and in some cases
> the latter is caused by the lack of resources at their end to conduct
> the same manual intervention of the former on the more recent
> releases.

speaking as a "distribution manager" (if i understand your terms
correctly), i am not "manually removing the bindings from the library".

debian administrators want modular systems, and some people run systems
with some dependencies installed; others do not.  Not everyone who wants
libgpgme11 wants the python bindings.

Furthermore, some gpgme python bindings are incompatible with some
versions of python, but this is not "sabotage" on the part of the
distribution manager" -- python3-gpg doesn't work with python3.7 in
debian because i *haven't* deviated from upstream practice, so the
package was built against python3.6 only.

distribution managers are *trying* to do the work needed to make the
GnuPG project easier to adopt on their distro.  As you've noticed from
thinking about the python bindings, it's quite difficult to do, because:

 a) merely shipping gpgme binary shared objects on a specific platform
    is a non-trivial task.

 b) getting the python bindings built against the current version of
    python is challenging, particularly if the user upgrades their own
    python installation.

 c) even if both of the above are sorted out, the GnuPG binary software
    itself (and all associated daemons) needs to be correctly installed
    for gpgme to work.

distro managers are just about the only people capable of sorting out
these complex dependency trees (binaries, shared-objects, python
bindings) and wrapping it all up into code that Just Works™.  If we're
failing, it's not due to some sort of sabotage, it's due to the
complexity of the GnuPG architecture.  Not many projects require both
shared objects and system-level binaries in order for the python
bindings to work :/  If you see a way to simplify this further, i'd be
happy to hear about it.

All the best,

             --dkg