Re: [Bug-pyconfigure] automake and pyconfigure: a future integration?

[Stefano Lattarini]

Hi Brandon.

On 12/13/2012 02:20 PM, Brandon Invergo wrote:
>>>
>> 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.
>
Would that also find a python 2.x interpreter names simply as "python"?

> 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)
>
(Nit: missing quotes; should be "m4_define([python_min_ver], [2.5])")
More important, you define this as a m4 macro ...

>     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))
>
... but later use it a shell variable.  What am I missing?

>     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.
>
Note that for "integration" I didn't mean merging your project into
Automake, but rather, having Automake leveraging on the m4 macros
provided by it; as we do with, say, the 'LT_INIT' libtool-provided
macro, without needing nor wanting it to be part of the Automake
core.

> 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. 
>
I think that would go more smoothly collaborating with the upstreams
from the beginning; for example, we had some tweaks and bug-fixes
related to python support in Automake (see in particular the commits
v1.12.4-43-ge0e99ed and v1.12.5-14-g1f113f6 in the Automake's git
repository), and you might want to backport some of them into
pyconfigure as well.

> 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
>
+1 from me!

> (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.
>
Makes sense.

> 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.
>
Well, at least those parts of Automake deals with python ;-)

And I'm open to such a rewrite, it it will brings clear advantages;
e.g., better integration/compatibility with distutils, setuptools
and/or distribute (or what the python distribution subsystem du-jour
is, sigh), clearer semantics, etc.

> 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).
>
No worry, once you have working rules, integrating them shouldn't
be difficult.  In view of such integration, you might want to start
clearing copyright issues ASAP though (that is, signing FSF papers
for Automake contributions).

> 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 address@hidden (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!
>
Thanks to you for starting that project, and for your quick feedback.

Best regards,
  Stefano