bug#28160: Support newer version of python

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

bug#28160: Support newer version of python

Mathieu Lirzin
Hello Bastien,

Bastien ROUCARIES <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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 (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#28160: Support newer version of python

Mathieu Lirzin
Hello,

Moritz Klammler <[hidden email]> 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