>>
> Me too, mostly. But I agree that there is an underlying issue (albeit
> not major).
>
>> The "Future Changes to this Recommendation"
>> section of PEP 394 anticipates changing the `python' symlink to
>> `python3' at some point in the future.
This has already happened in Parabola, Arch and other similar distros. I
think it's best, with an eye to the future, to keep python3 at the front
of searches.
>>
>> 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 happens in pyconfigure (more on that in a moment) is that you can
pass an argument to AC_PROG_PYTHON. So if you want to use Python 2
specifically, you first search for it with AC_PROG_PYTHON([python2]). In
a standard system, this should find the most recent Python 2
interpreter. If it doesn't find anything, then do AC_PROG_PYTHON without
an argument to search the full list. If a Python 3 interpreter is found,
then that likely means that `python' in PATH refers to Python 3 and that
if Python 2 *is* installed, it's installed in some weird, non-standard
way. In that case, the user can always pass in the PYTHON env variable
as an argument to configure.
Here's an example configure.ac chunk to do that using Pyconfigure's
macros:
m4_define(python_min_ver, 2.5)
AC_PROG_PYTHON([python2])
if [[ "x$PYTHON" == "x" ]]; then
AC_PROG_PYTHON
PC_PYTHON_VERIFY_VERSION(3.0, ,
AC_MSG_ERROR(Python 2 ($python_min_ver+) is required))
fi
>
> 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:
>
> <https://www.gnu.org/software/pyconfigure/>
>
> 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 ...
I know that I have not yet communicated with the Auto{make,conf} devs
enough about integrating the pyconfigure files upstream. Needless to
say, it's easiest for me to work on them and tweak them from the comfort
of a project that I maintain. So, I'm waiting until I get all the bugs
and kinks (like version checking) worked out so that they require as
little further work as possible upstream.
Currently there is Python stuff spread out between Autoconf-archive,
Automake, and now Pyconfigure. I'm hoping to integrate the core of that
functionality into a robust set of macros in Pyconfigure (obviously some
specialized things can/should stay in autoconf-archive). I think these
core macros will be most appropriately integrated into Autoconf, since I
have implemented Python as an AC_LANG.
Future integration with Automake will be necessary. This is a bit of a
hand-wavy explanation but here it goes: currently Pyconfigure provides a
standard-GNU-style wrapper around Python's distutils setup.py; the next
step is to also offer the reverse, meaning a setup.py that essentially
calls the standard GNU stuff. Since Pyconfigure is all about making
things as easy as possible for maintaining these different build
procedures, very way that I think about it, I realize
that I would be largely rewriting Automake. What I will do is start to
implement it very manually in the Makefile.in and once I have a clear
idea of my needs, I'll bring it to you guys to see how we can implement
it (sadly, I don't know the inner workings of Automake). But basically,
as long as Automake's installation of Python libraries is working fine
(installing to $(pkgpythondir)), it should be straight-forward. I'll
test it out soon to see how it goes.
For those who aren't familiar with it, the purpose of Pyconfigure is to
provide a useful set of template files for Python developers to
integrate into their own projects to facilitate using the standard GNU
configure/install procedure. This can be done alongside an existing
setup.py file or, eventually, instead of one if you want. Pyconfigure's
Python macros are generally adapted from the ones included in Automake,
plus a few that I wrote. So, old configure.ac scripts probably wouldn't
need too much adaptation to use them. You can see the code here:
http://git.savannah.gnu.org/cgit/pyconfigure.git/tree/
(the templates are in the src/ directory)
I gladly welcome any comments, suggestions, patches, etc.! I have the
mailing list bug-pyconfig...@gnu.org (currently requires subscription
or manual approval by me due to overwhelming spam), as CCed in this
email, where you can contact me.
Thanks Stefano for bringing this conversation to my attention!
Cheers,
Brandon
