Port GPGME's Python bindings to Windows
Open, HighPublic

werner created this task.Nov 15 2017, 9:11 AM
BenM added a subscriber: BenM.Apr 11 2018, 3:41 AM
werner moved this task from Backlog to Python on the gpgme board.Apr 19 2018, 6:08 PM
BenM claimed this task.Apr 30 2018, 12:43 AM

Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).

Testing this is already on my todo list, but it'd probably require a very static build so that it can be made to work on whatever type of Windows system people have. As distinct from the complete lack of them here (unsurprisingly).

BenM added a comment.Jul 5 2018, 8:15 AM

Though a CFFI/ABI solution may be the only option, it would still be preferable to get SWIG working under Windows. The reasons for this are many, but not least of which would include not needing to duplicate effort to accommodate Windows, no functionality mismatch due to using the Windows version and not needing to implement every function manually since CFFI can't generate low level bindings the same way that SWIG does.

This has meant delving a little deeper into SWIG's documentation and one matter which needs confirmation relates to the compilers used to build GPGME, SWIG and Python on Windows systems. It is possible that for at least those three things and possibly for the rest of the GnuPG stack as well, they all need to be the same compiler and libraries. SWIG, however, includes a requirement that it must be built with the GNU utilities and nothing else. The GnuPG stack has no problems with that restriction if necessary and Python can be compiled with it too. It is, however, highly likely that Windows users are not installing Python by compiling it from source themselves, it is more likely that they're using the Windows installers available from the Python website and for fairly understandable reasons. Still, it could very well be that that precompiled version of Python is what cannot work with SWIG rather than Windows in general.

Unfortunately confirmation of this theory requires access to a Windows environment to develop and test in which is presently unavailable.

Whereas it is possible that a variation on a possible solution for another platform which could also be developed on a non-Windows platform could become an alternative option here. This, however, requires a little more investigation too which may be conducted during the course of other aspects of the bindings development.

BenM added a comment.Aug 7 2018, 5:58 AM

Windows 10 was obtained last week and the process of preparing a Windows build env began earlier today.

I now remember why I loathe this operating system.

Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.

A subsequent discussion with @aheinecke led to raising the possibility of including a precompiled build of the bindings for whatever the latest stable CPython minor version is released from python.org and including that as an optional extra with GPG4Win.

If testing of this is successful then we can at least provide an “out of the box” solution for Windows users with whatever is current at the time and, of course, a replicatable build process for others to adapt to their own circumstances if necessary.

It will not, however, be feasible to provide multiple CPython version builds simultaneously, as can currently be built by default with installations on POSIX systems. On the other hand, it would mean we could maintain the standard answer regarding doing anything with GnuPG on Windows and cite Intevation and GPG4Win as the solution.

BenM added a comment.EditedDec 15 2018, 8:18 PM

Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:


Specifically that the MSYS2 devs are explicitly not supporting 64-bit architecture.

So that's that. It also indicates that their project will dead end in early 2038, if not before.

Reading through this issue and the related documentation: Thanks for writing this all down and adding links!

Especially interesting is

How can we move forward?
Guidance maybe provided by the question: What would be the platform most useful to users?

What about trying to build versions for the current stable version of the default CPython build?
According to https://www.python.org/downloads/windows/ this would be Python 3.7.2
and as most new versions are 64 bit, so we'd have the following list, in decreasing importance:

  1. CPython 3.7.2 x86-64 (for both Intel and AMD according to https://www.python.org/downloads/release/python-372/
  2. CPython 3.7.2 32bit
  3. CPython 2.7.16 32bit (probably also useful on 64bit operating systems)

There are Visual Studio 2015 or later Azure images, which could be rented for automated builds in theory.
We could also ask the Python Software Foundation how they are preparing their releases.

Once we have build one useful version, we could identify the next useful one.
And we could also evaluate our options. Beside CFFI there is also the possibility to hand-craft a python extension module.