lang/python/doc/texinfo/short-history.texi

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