python bindings: CPython order
authorBen McGinnes <ben@adversary.org>
Tue, 2 Oct 2018 20:58:51 +0000 (06:58 +1000)
committerBen McGinnes <ben@adversary.org>
Tue, 2 Oct 2018 20:58:51 +0000 (06:58 +1000)
* Changed the order of python versions the configure/make process
  checks for, placing Python 3.7 ahead of 3.6.
* Updated the HOWTO documentation to reflect this change.

Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
doc/gpgme-python-howto.texi
lang/python/docs/gpgme-python-howto.org
m4/python.m4

index 5f33f5d..c88c746 100644 (file)
@@ -257,6 +257,9 @@ The release of Python 3.7.0; which appears to be working just fine
 with our bindings, in spite of intermittent reports of problems for
 many other Python projects with that new release.
 @item
+Python 3.7 has been moved to the head of the specified python
+versions list in the build process.
+@item
 In order to fix some other issues, there are certain underlying
 functions which are more exposed through the @ref{Context, , gpg.Context()}, but
 ongoing documentation ought to clarify that or otherwise provide the
@@ -521,9 +524,25 @@ For Python 2 it checks for these executables in this order: @samp{python},
 @samp{python2} and @samp{python2.7}.
 
 For Python 3 it checks for these executables in this order: @samp{python3},
-@samp{python3.6}, @samp{python3.5}, @samp{python3.4} and @samp{python3.7}.@footnote{As Python 3.7 is a very recent release, it is not given
-priority over 3.6 yet, but will probably be prioritised by the release
-of Python 3.7.2.}
+ @samp{python3.7}, @samp{python3.6}, @samp{python3.5} and @samp{python3.4}.@footnote{With no issues reported specific to Python 3.7, the release of
+Python 3.7.1 at around the same time as GPGME 1.12.0 and the testing
+with Python 3.7.1rc1, there is no reason to delay moving 3.7 ahead of
+3.6 now.  Production environments with more conservative requirements
+will always enforce their own policies anyway and installation to each
+supported minor release is quite possible too.}
+
+On systems where @samp{python} is actually @samp{python3} and not @samp{python2} it
+may be possible that @samp{python2} may be overlooked, but there have been
+no reports of that actually occurring as yet.
+
+In the three months or so since the release of Python 3.7.0 there has
+been extensive testing and work with these bindings with no issues
+specifically relating to the new version of Python or any of the new
+features of either the language or the bindings.  This has also been
+the case with Python 3.7.1rc1.  With that in mind and given the
+release of Python 3.7.1 is scheduled for around the same time as GPGME
+1.12.0, the order of preferred Python versions has been changed to
+move Python 3.7 ahead of Python 3.6.
 
 @menu
 * Installing GPGME::
@@ -1636,10 +1655,10 @@ else:
     pass
 @end example
 
-It is important to note that the result will only return @samp{None} when a
-pattern has been entered for @samp{logrus}, but it has not matched any
-keys. When the search pattern itself is set to @samp{None} this triggers
-the exporting of the entire public keybox.
+It should be noted that the result will only return @samp{None} when a
+search pattern has been entered, but has not matched any keys.  When
+the search pattern itself is set to @samp{None} this triggers the exporting
+of the entire public keybox.
 
 @example
 import gpg
index d3695c3..c7a1f82 100644 (file)
@@ -98,6 +98,8 @@ The bullet points of new additiions are:
 - The release of Python 3.7.0; which appears to be working just fine
   with our bindings, in spite of intermittent reports of problems for
   many other Python projects with that new release.
+- Python 3.7 has been moved to the head of the specified python
+  versions list in the build process.
 - In order to fix some other issues, there are certain underlying
   functions which are more exposed through the [[#howto-get-context][gpg.Context()]], but
   ongoing documentation ought to clarify that or otherwise provide the
@@ -354,7 +356,20 @@ For Python 2 it checks for these executables in this order: =python=,
 =python2= and =python2.7=.
 
 For Python 3 it checks for these executables in this order: =python3=,
-=python3.6=, =python3.5=, =python3.4= and =python3.7=.[fn:3]
+ =python3.7=, =python3.6=, =python3.5= and =python3.4=.[fn:3]
+
+On systems where =python= is actually =python3= and not =python2= it
+may be possible that =python2= may be overlooked, but there have been
+no reports of that actually occurring as yet.
+
+In the three months or so since the release of Python 3.7.0 there has
+been extensive testing and work with these bindings with no issues
+specifically relating to the new version of Python or any of the new
+features of either the language or the bindings.  This has also been
+the case with Python 3.7.1rc1.  With that in mind and given the
+release of Python 3.7.1 is scheduled for around the same time as GPGME
+1.12.0, the order of preferred Python versions has been changed to
+move Python 3.7 ahead of Python 3.6.
 
 
 *** Installing GPGME
@@ -1481,10 +1496,10 @@ else:
     pass
 #+END_SRC
 
-It is important to note that the result will only return =None= when a
-pattern has been entered for =logrus=, but it has not matched any
-keys. When the search pattern itself is set to =None= this triggers
-the exporting of the entire public keybox.
+It should be noted that the result will only return =None= when a
+search pattern has been entered, but has not matched any keys.  When
+the search pattern itself is set to =None= this triggers the exporting
+of the entire public keybox.
 
 #+BEGIN_SRC python -i
 import gpg
@@ -2986,9 +3001,12 @@ PURPOSE.
 
 [fn:2] The =lang/python/docs/= directory in the GPGME source.
 
-[fn:3] As Python 3.7 is a very recent release, it is not given
-priority over 3.6 yet, but will probably be prioritised by the release
-of Python 3.7.2.
+[fn:3] With no issues reported specific to Python 3.7, the release of
+Python 3.7.1 at around the same time as GPGME 1.12.0 and the testing
+with Python 3.7.1rc1, there is no reason to delay moving 3.7 ahead of
+3.6 now.  Production environments with more conservative requirements
+will always enforce their own policies anyway and installation to each
+supported minor release is quite possible too.
 
 [fn:4] Yes, even if you use virtualenv with everything you do in
 Python.  If you want to install this module as just your user account
index 56220ba..7097db2 100644 (file)
@@ -40,8 +40,8 @@ AC_DEFUN([AM_PATH_PYTHON],
   m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
 [python2 python2.7 dnl
  python dnl
- python3 python3.6 python3.5 python3.4 python3.7  dnl
python3.8])
+ python3 python3.7 python3.6 python3.5 python3.4 dnl python3.8
+ ])
 
   AC_ARG_VAR([PYTHON], [the Python interpreter])