GNU bug report logs - #28160
Support newer version of python

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28160 in the body.
You can then email your comments to 28160 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bastien ROUCARIES <roucaries.bastien <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Support newer version of python
Date: Sun, 20 Aug 2017 14:34:30 +0200

Hi,

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

Thanks

Message #8 received at 28160 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Bastien ROUCARIES <roucaries.bastien <at> gmail.com>
Cc: 28160 <at> debbugs.gnu.org
Subject: Re: bug#28160: Support newer version of python
Date: Fri, 15 Sep 2017 11:17:48 +0200

Hello Bastien,

Bastien ROUCARIES <roucaries.bastien <at> gmail.com> 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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thomas Jahns <jahns <at> dkrz.de>
To: bug-automake <at> gnu.org
Subject: Re: bug#28160: Support newer version of python
Date: Fri, 15 Sep 2017 11:42:34 +0200

[Message part 1 (text/plain, inline)]

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 (application/pkcs7-signature, attachment)]

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Moritz Klammler <moritz <at> klammler.eu>
To: bug-automake <at> gnu.org
Subject: Re: bug#28160: Support newer version of python
Date: Fri, 15 Sep 2017 16:57:30 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #17 received at 28160 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Moritz Klammler <moritz <at> klammler.eu>
Cc: 28160 <at> debbugs.gnu.org
Subject: Re: bug#28160: Support newer version of python
Date: Fri, 22 Sep 2017 11:08:45 +0200

Hello,

Moritz Klammler <moritz <at> klammler.eu> 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

Message #22 received at 28160 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Bastien ROUCARIES <roucaries.bastien <at> gmail.com>
Cc: 28160 <at> debbugs.gnu.org, Moritz Klammler <moritz <at> klammler.eu>,
 Thomas Jahns <jahns <at> dkrz.de>
Subject: Re: bug#28160: Support newer version of python
Date: Sun, 04 Feb 2018 01:53:29 +0100

[Message part 1 (text/plain, inline)]

Hello,

Mathieu Lirzin <mthl <at> gnu.org> 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.

[0001-python-Generate-python-interpreter-list.patch (text/x-patch, inline)]

From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl <at> gnu.org>
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

[Message part 3 (text/plain, inline)]

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

Message #29 received at 28160 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Bastien ROUCARIES <roucaries.bastien <at> gmail.com>
Cc: 28160 <at> debbugs.gnu.org, Moritz Klammler <moritz <at> klammler.eu>,
 Thomas Jahns <jahns <at> dkrz.de>
Subject: Re: bug#28160: Support newer version of python
Date: Sun, 18 Feb 2018 12:34:49 +0100

Mathieu Lirzin <mthl <at> gnu.org> writes:

>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <mthl <at> gnu.org>
> 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

Message #40 received at 28160 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Bastien ROUCARIES <roucaries.bastien <at> gmail.com>
Cc: 28160 <at> debbugs.gnu.org, Moritz Klammler <moritz <at> klammler.eu>,
 Thomas Jahns <jahns <at> dkrz.de>
Subject: Re: bug#28160: Support newer version of python
Date: Sat, 03 Mar 2018 13:00:22 +0100

[Message part 1 (text/plain, inline)]

Hello,

Mathieu Lirzin <mthl <at> gnu.org> writes:

> Mathieu Lirzin <mthl <at> gnu.org> writes:
>
>>>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin <mthl <at> gnu.org>
>> 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.

[0001-python-Support-future-python-version-up-to-3.9.patch (text/x-patch, inline)]

From 88df0576249df21e719ff3ac95d3d27b77e3370f Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl <at> gnu.org>
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

[Message part 3 (text/plain, inline)]

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

Message #45 received at 28160-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Bastien ROUCARIES <roucaries.bastien <at> gmail.com>
Cc: 28160-done <at> debbugs.gnu.org, Moritz Klammler <moritz <at> klammler.eu>,
 Thomas Jahns <jahns <at> dkrz.de>
Subject: Re: bug#28160: Support newer version of python
Date: Thu, 08 Mar 2018 21:38:24 +0100

Mathieu Lirzin <mthl <at> gnu.org> 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 <mthl <at> gnu.org>
> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.