1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
\input texinfo @c -*- texinfo -*-
@c %**start of header
@setfilename short-history.info
@settitle A Short History of the GPGME bindings for Python
@documentencoding UTF-8
@documentlanguage en
@c %**end of header
@finalout
@titlepage
@title A Short History of the GPGME bindings for Python
@author Ben McGinnes
@end titlepage
@contents
@ifnottex
@node Top
@top A Short History of the GPGME bindings for Python
@end ifnottex
@menu
* Overview::
* Relics of the past::
@detailmenu
--- The Detailed Node Listing ---
Overview
* In the beginning::
* Keeping the flame alive::
* Passing the torch::
* Coming full circle::
Relics of the past
* The Annoyances of Git::
* The Perils of PyPI::
The Perils of PyPI
* GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library::
* PyME 0·9·0 - Python support for GPGME GnuPG cryptography library::
@end detailmenu
@end menu
@node Overview
@chapter Overview
The GPGME Python bindings passed through many hands and numerous
phases before, after a fifteen year journey, coming full circle to
return to the source. This is a short explanation of that journey.
@menu
* In the beginning::
* Keeping the flame alive::
* Passing the torch::
* Coming full circle::
@end menu
@node In the beginning
@section In the beginning
In 2002 John Goerzen released PyME; Python bindings for the GPGME
module which utilised the current release of Python of the time and
SWIG.@footnote{In all likelihood thos would have been Python 2.2 or possibly
Python 2.3.} Shortly after creating it and ensuring it worked he stopped
supporting it, though he left his work available on his Gopher
site.
@node Keeping the flame alive
@section Keeping the flame alive
A couple of years later the project was picked up by Igor Belyi and
actively developed and maintained by him from 2004 to 2008. Igor's
whereabouts at the time of this document's creation are unknown,
but the current authors do hope he is well. We're assuming (or
hoping) that life did what life does and made continuing untenable.
@node Passing the torch
@section Passing the torch
In 2014 Martin Albrecht wanted to patch a bug in the PyME code and
discovered the absence of Igor. Following a discussion on the PyME
mailing list he became the new maintainer for PyME, releasing
version 0.9.0 in May of that year. He remains the maintainer of
the original PyME release in Python 2.6 and 2.7 (available via
PyPI).
@node Coming full circle
@section Coming full circle
In 2015 Ben McGinnes approached Martin about a Python 3 version,
while investigating how complex a task this would be the task ended
up being completed. A subsequent discussion with Werner Koch led
to the decision to fold the Python 3 port back into the original
GPGME release in the languages subdirectory for non-C bindings
under the module name of @samp{pyme3}.
In 2016 this PyME module was integrated back into the GPGME project
by Justus Winter. During the course of this work Justus adjusted
the port to restore limited support for Python 2, but not as many
minor point releases as the original PyME package supports. During
the course of this integration the package was renamed to more
accurately reflect its status as a component of GPGME. The @samp{pyme3}
module was renamed to @samp{gpg} and adopted by the upstream GnuPG team.
In 2017 Justus departed G10code and the GnuPG team. Following this
Ben returned to maintain of gpgme Python bindings and continue
building them from that point.
@node Relics of the past
@chapter Relics of the past
There are a few things, in addition to code specific factors, such as
SWIG itself, which are worth noting here.
@menu
* The Annoyances of Git::
* The Perils of PyPI::
@end menu
@node The Annoyances of Git
@section The Annoyances of Git
As anyone who has ever worked with git knows, submodules are
horrible way to deal with pretty much anything. In the interests
of avoiding migraines, that was skipped with addition of the PyME
code to GPGME.
Instead the files were added to a subdirectory of the @samp{lang/}
directory, along with a copy of the entire git log up to that point
as a separate file within the @samp{lang/python/docs/} directory.@footnote{The entire PyME git log and other preceding VCS logs are
located in the @samp{gpgme/lang/python/docs/old-commits.log} file.}
As the log for PyME is nearly 100KB and the log for GPGME is
approximately 1MB, this would cause considerable bloat, as well as
some confusion, should the two be merged.
Hence the unfortunate, but necessary, step to simply move the
files. A regular repository version has been maintained should it
be possible to implement this better in the future.
@node The Perils of PyPI
@section The Perils of PyPI
The early port of the Python 2 @samp{pyme} module as @samp{pyme3} was never
added to PyPI while the focus remained on development and testing
during 2015 and early 2016. Later in 2016, however, when Justus
completed his major integration work and subsequently renamed the
module from @samp{pyme3} to @samp{gpg}, some prior releases were also
provided through PyPI.
Since these bindings require a matching release of the GPGME
libraries in order to function, it was determined that there was
little benefit in also providing a copy through PyPI since anyone
obtaining the GPGME source code would obtain the Python bindings
source code at the same time. Whereas there was the potential to
sew confusion amongst Python users installing the module from PyPI,
only to discover that without the relevant C files, header files or
SWIG compiled binaries, the Python module did them little good.
There are only two files on PyPI which might turn up in a search
for this module or a sample of its content:
@enumerate
@item
gpg (1.8.0) - Python bindings for GPGME GnuPG cryptography library
@item
pyme (0.9.0) - Python support for GPGME GnuPG cryptography library
@end enumerate
@menu
* GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library::
* PyME 0·9·0 - Python support for GPGME GnuPG cryptography library::
@end menu
@node GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library
@subsection GPG 1·8·0 - Python bindings for GPGME GnuPG cryptography library
This is the most recent version to reach PyPI and is the version
of the official Pyhon bindings which shipped with GPGME 1.8.0. If
you have GPGME 1.8.0 installed and @emph{only} 1.8.0 installed, then it
is probably safe to use this copy from PyPI.
As there have been a lot of changes since the release of GPGME
1.8.0, the GnuPG Project recommends not using this version of the
module and instead installing the current version of GPGME along
with the Python bindings included with that package.
@node PyME 0·9·0 - Python support for GPGME GnuPG cryptography library
@subsection PyME 0·9·0 - Python support for GPGME GnuPG cryptography library
This is the last release of the PyME bindings maintained by Martin
Albrecht and is only compatible with Python 2, it will not work
with Python 3. This is the version of the software from which the
port from Python 2 to Python 3 code was made in 2015.
Users of the more recent Python bindings will recognise numerous
points of similarity, but also significant differences. It is
likely that the more recent official bindings will feel "more
pythonic."
For those using Python 2, there is essentially no harm in using
this module, but it may lack a number of more recent features
added to GPGME.
@bye
|
