[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-pyconfigure] automake and pyconfigure: a future integration? (was:
[Bug-pyconfigure] automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)
Thu, 13 Dec 2012 13:54:27 +0100
[+cc bug-automake, +cc bug-pyconfigure]
On 12/13/2012 11:15 AM, Jack Kelly wrote:
> Kerrick Staley <address@hidden> writes:
>> Usually, when AM_PATH_PYTHON is invoked with an argument of the form
>> 2.X, it means that only a Python 2 interpreter should be used, and not
>> a Python 3 interpreter. However, the "python" command invokes a Python
>> 3 interpreter on some systems (see ), so if we try "python" first,
>> we may get a Python 3 interpreter when really a Python 2 interpreter is
>> needed. By changing the precedence so that the "python2(.X)" commands
>> are tried first, a Python 2 interpreter will always be used if one is
>> available (and of sufficiently high version).
>>  http://www.python.org/dev/peps/pep-0394/
> I disagree with this patch.
Me too, mostly. But I agree that there is an underlying issue (albeit
> The "Future Changes to this Recommendation"
> section of PEP 394 anticipates changing the `python' symlink to
> `python3' at some point in the future.
> I think a better patch would change the search list based on the major
> version passed as the first argument to AM_PATH_PYTHON:
> a) If it's 2.x, search `python2 python2.7 python2.6 ... python'.
> b) If it's 3.x, search `python3 python3.3 python3.2 python3.1 ... python'.
> c) If nothing's given, search `python python2 python2.7 ... python2.0
> python3 python3.2 ... python3.0.'
> In case (c), swap the search order to search python3 interpreters first
> once PEP 394 updates its recommendation to make python symlink to a
> python 3 interpreter.
This sounds quite complex; too much, honestly.
What is more important, I don't think we should work on, tweak, nor
improve AM_PATH_PYTHON anymore. In fact, there is a new GNU project
that aims at providing better autoconfigry integration for python:
So I think that, instead of adding new code and semantics to automake,
we should work toward improving that package, and integrate with it
once it's mature enough (then we could deprecate, and some time in
the future remove, the AM_PATH_PYTHON macro from automake).
I've added the bug-pyconfigure in CC: to contact the author of that
package, and hear his opinion on the matter. Maybe we can start
sketching out a roadmap and a TODO list ...
> Question: should this dispatch be done at `autoconf' time (via m4) or at
> `./configure' time (via sh)? If a package wants to support python 2 and
> 3, I think they should inspect $PYTHON after a call to AM_PATH_PYTHON,
> and not pass a shell variable as the first argument. Is there an
> automake convention about which arguments can safely hold shell
> -- Jack
- [Bug-pyconfigure] automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first),
Stefano Lattarini <=