bug#28160: Support newer version of python

[Mathieu Lirzin]

Mathieu Lirzin  writes:

> Here is an alternative patch to fixes this bug, that I intend to push
> tomorrow.
>
>>From 88df0576249df21e719ff3ac95d3d27b77e3370f Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Sat, 3 Mar 2018 12:01:13 +0100
> Subject: [PATCH] python: Support future python version up to 3.9
>
> This change fixes automake bug#28160.
>
> Since AM_PYTHON_PATH macro takes no maximum version argument, there is
> no need to generate _AM_PYTHON_INTERPRETER_LIST dynamically, like what
> was previously done by the reverted commit
> 1d60fb72168e62d33fe433380af621de64e22f23.  We could rely on M4 to
> generate this list statically however this is likely to be a complex
> solution that would not improve maintainability.
>
> * m4/python.m4 (_AM_PYTHON_INTERPRETER_LIST): Add 'python3.7',
> 'python3.8', and 'python3.9'.
> ---

Pushed as commit 9385c161707c6d2295d610eef81fe4d1a44b44de.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Mathieu Lirzin]

Hello,

Mathieu Lirzin  writes:

> Mathieu Lirzin  writes:
>
From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin 
>> Date: Thu, 1 Feb 2018 13:51:03 +0100
>> Subject: [PATCH] python: Generate python interpreter list
>>
>> _AM_PYTHON_INTERPRETER_LIST is used by AM_PYTHON_PATH to autodetect
>> Python programs whose names correspond to a specific Python
>> version (e.g. python3.6).  Previously this list was updated manually.
>> The automatic support of newer versions (up to 4.0 excluded) fixes
>> bug#28160.
>>
>> * m4/python.m4 (am_py_min_ver, am_py_max_ver): New macros.
>> (_AM_PYTHON_INTERPRETER_LIST): Generate this list instead of hard-coding
>> it.  Implementation is taken from GNU Pyconfigure.
>> ---
>>  m4/python.m4 | 21 +
>>  1 file changed, 17 insertions(+), 4 deletions(-)
>
> Pushed as commit 1d60fb72168e62d33fe433380af621de64e22f23

This commit has brought the issue described in automake bug#30616 [1].

I initially was not happy with solution of manually defining future
versions, but after reflection it seems that the maintainability issue
of updating it manually doesn't worth the complexity of generating it
with M4.  Here is an alternative patch to fixes this bug, that I intend
to push tomorrow.

>From 88df0576249df21e719ff3ac95d3d27b77e3370f Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Sat, 3 Mar 2018 12:01:13 +0100
Subject: [PATCH] python: Support future python version up to 3.9

This change fixes automake bug#28160.

Since AM_PYTHON_PATH macro takes no maximum version argument, there is
no need to generate _AM_PYTHON_INTERPRETER_LIST dynamically, like what
was previously done by the reverted commit
1d60fb72168e62d33fe433380af621de64e22f23.  We could rely on M4 to
generate this list statically however this is likely to be a complex
solution that would not improve maintainability.

* m4/python.m4 (_AM_PYTHON_INTERPRETER_LIST): Add 'python3.7',
'python3.8', and 'python3.9'.
---
 m4/python.m4 | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/m4/python.m4 b/m4/python.m4
index 58dd18761..63c0a0e04 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -36,11 +36,12 @@ AC_DEFUN([AM_PATH_PYTHON],
  [
   dnl Find a Python interpreter.  Python versions prior to 2.0 are not
   dnl supported. (2.0 was released on October 16, 2000).
-  dnl FIXME: Remove the need to hard-code Python versions here.
   m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
-[python python2 python3 python3.6 python3.5 python3.4 python3.3 python3.2 dnl
- python3.1 python3.0 python2.7 python2.6 python2.5 python2.4 python2.3 dnl
- python2.2 python2.1 python2.0])
+[python python2 python3 dnl
+ python3.9 python3.8 python3.7 python3.6 python3.5 python3.4 python3.3 dnl
+ python3.2 python3.1 python3.0 dnl
+ python2.7 python2.6 python2.5 python2.4 python2.3 python2.2 python2.1 dnl
+ python2.0])
 
   AC_ARG_VAR([PYTHON], [the Python interpreter])
 
-- 
2.16.2


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30616
-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Mathieu Lirzin]

Mathieu Lirzin  writes:

>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Thu, 1 Feb 2018 13:51:03 +0100
> Subject: [PATCH] python: Generate python interpreter list
>
> _AM_PYTHON_INTERPRETER_LIST is used by AM_PYTHON_PATH to autodetect
> Python programs whose names correspond to a specific Python
> version (e.g. python3.6).  Previously this list was updated manually.
> The automatic support of newer versions (up to 4.0 excluded) fixes
> bug#28160.
>
> * m4/python.m4 (am_py_min_ver, am_py_max_ver): New macros.
> (_AM_PYTHON_INTERPRETER_LIST): Generate this list instead of hard-coding
> it.  Implementation is taken from GNU Pyconfigure.
> ---
>  m4/python.m4 | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)

Pushed as commit 1d60fb72168e62d33fe433380af621de64e22f23

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Mathieu Lirzin]

Hello,

Mathieu Lirzin  writes:

>>> On 09/15/17 11:17, Mathieu Lirzin wrote:
 Instead of preemptively adding possible future version of Python that
 hopefully would be released, I would prefer a solution that removes the
 need to hard-code them.
>
> It seems that GNU Pyconfigure has already found a way to build that list
> dynamically in m4.  Please see PC_PROG_PYTHON macro here:
>
>   https://git.savannah.gnu.org/cgit/pyconfigure.git/tree/src/m4/python.m4

I have adapted this to fit Automake context.  I am going to apply the
following patch in the following days.  Comments welcome.

>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Thu, 1 Feb 2018 13:51:03 +0100
Subject: [PATCH] python: Generate python interpreter list

_AM_PYTHON_INTERPRETER_LIST is used by AM_PYTHON_PATH to autodetect
Python programs whose names correspond to a specific Python
version (e.g. python3.6).  Previously this list was updated manually.
The automatic support of newer versions (up to 4.0 excluded) fixes
bug#28160.

* m4/python.m4 (am_py_min_ver, am_py_max_ver): New macros.
(_AM_PYTHON_INTERPRETER_LIST): Generate this list instead of hard-coding
it.  Implementation is taken from GNU Pyconfigure.
---
 m4/python.m4 | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/m4/python.m4 b/m4/python.m4
index 58dd18761..d6dda1363 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -36,11 +36,24 @@ AC_DEFUN([AM_PATH_PYTHON],
  [
   dnl Find a Python interpreter.  Python versions prior to 2.0 are not
   dnl supported. (2.0 was released on October 16, 2000).
-  dnl FIXME: Remove the need to hard-code Python versions here.
+  m4_define_default([am_py_min_ver], m4_ifval([$1], [$1], [2.0]))
+  dnl The arbitrary default maximum version.
+  m4_define_default([am_py_max_ver], [4.0])
+
   m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
-[python python2 python3 python3.6 python3.5 python3.4 python3.3 python3.2 dnl
- python3.1 python3.0 python2.7 python2.6 python2.5 python2.4 python2.3 dnl
- python2.2 python2.1 python2.0])
+[[python] \
+ dnl If we want some Python 2 versions (min version <= 2.7),
+ dnl also search for "python2".
+ m4_if(m4_version_compare(am_py_min_ver, [2.8]), [-1], [python2], []) \
+ [python3] \
+ dnl Construct a comma-separated list of interpreter names (python2.6,
+ dnl python2.7, etc). We only care about the first 3 characters of the
+ dnl version strings (major-dot-minor; not
+ dnl major-dot-minor-dot-bugfix[-dot-whatever])
+ m4_foreach([py_ver],
+   m4_esyscmd_s(seq -s[[", "]] -f["[[%.1f]]"] m4_substr(am_py_max_ver, [0], [3]) -0.1 m4_substr(am_py_min_ver, [0], [3])),
+   dnl Remove python2.8 and python2.9 since they will never exist
+   [m4_bmatch(py_ver, [2.[89]], [], [python]py_ver)])])
 
   AC_ARG_VAR([PYTHON], [the Python interpreter])
 
-- 
2.16.1


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Moritz Klammler]

On 09/15/2017 11:42 AM, Thomas Jahns wrote:
> On 09/15/17 11:17, Mathieu Lirzin wrote:
>> Instead of preemptively adding possible future version of Python that
>> hopefully would be released, I would prefer a solution that removes the
>> need to hard-code them.
>>
>> WDYT?
> 
> Why not parse PATH and filter what pathelem/python* returns for a
> pattern like
> 
> python[0-9.]*
> 
> then test for executability and extract numerically highest (that's
> probably the hardest part) suffix?
> 
> Regards, Thomas


AFAIK, all versions of Python let you do

$ python -c 'import sys; print(sys.hexversion);'

to print an integer that is increasing strictly monotonic between
releases.  Might be a good way to combine testing whether an executable
file really is a Python interpreter and finding the newest one among
those.  Instead of parsing version numbers, you can then simply compare
plain integers which is easy to do in the shell.

On the other hand, the "hexversion" can be easily computed given a major
and minor version number:

https://docs.python.org/3.7/c-api/apiabiversion.html#apiabiversion



signature.asc
Description: OpenPGP digital signature

bug#28160: Support newer version of python

[Thomas Jahns]

On 09/15/17 11:17, Mathieu Lirzin wrote:

Instead of preemptively adding possible future version of Python that
hopefully would be released, I would prefer a solution that removes the
need to hard-code them.

WDYT?


Why not parse PATH and filter what pathelem/python* returns for a pattern like

python[0-9.]*

then test for executability and extract numerically highest (that's probably the 
hardest part) suffix?


Regards, Thomas



smime.p7s
Description: S/MIME Cryptographic Signature

bug#28160: Support newer version of python

[Mathieu Lirzin]

Hello Bastien,

Bastien ROUCARIES  writes:

> Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872052
> could you suppoort python3.8 python3.7 and python3.6 ?

Python 3.6 is already added In last release 1.15.1.

Since Python 3.7 and 3.8 are not release yet, I am not comfortable
adding those in the hard-coded list from m4/python.m4.  As stated in the
inline FIXME comment below, we are aware that the current detection of
python is not future proof:

--8<---cut here---start->8---
AC_DEFUN([AM_PATH_PYTHON],
 [
  dnl Find a Python interpreter.  Python versions prior to 2.0 are not
  dnl supported. (2.0 was released on October 16, 2000).
  dnl FIXME: Remove the need to hard-code Python versions here.
  m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
[python python2 python3 python3.6 python3.5 python3.4 python3.3 python3.2 dnl
 python3.1 python3.0 python2.7 python2.6 python2.5 python2.4 python2.3 dnl
 python2.2 python2.1 python2.0])
--8<---cut here---end--->8---

Instead of preemptively adding possible future version of Python that
hopefully would be released, I would prefer a solution that removes the
need to hard-code them.

WDYT?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Bastien ROUCARIES]

Hi,

Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872052
could you suppoort python3.8 python3.7 and pyhton3.6 ?

Thanks