bug#28160: Support newer version of python
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
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 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
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
Hello, Moritz Klammler writes: > 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 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 am far from an m4 expert, so if someone is interested in porting that macro to Automake, please step up. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
bug#28160: Support newer version of python
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
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
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
Hi, Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872052 could you suppoort python3.8 python3.7 and pyhton3.6 ? Thanks