Python min version bumped from 2.4+ to 2.5+

[Greg Larkin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/30/11 4:25 PM, Ruslan Mahmatkhanov wrote:
> Greg Larkin wrote on 31.08.2011 00:07:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 8/30/11 10:26 AM, Ruslan Mahmatkhanov wrote:
>>> Greg Larkin wrote on 30.08.2011 17:56:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote:
>>>>> Greg Larkin wrote on 30.08.2011 17:05:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> I have a question about a commit you made in February 2011:
>>>>>> http://www.freshports.org/commit.php?message_id=201102250750.p1P7ofDg016541@repoman.freebsd.org&files=yes
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Part of the commit changed:
>>>>>>
>>>>>> USE_PYTHON=    2.4+
>>>>>>
>>>>>> to
>>>>>>
>>>>>> USE_PYTHON=    2.5+
>>>>>>
>>>>>> Was there a specific reason for doing so?  I am running various
>>>>>> tinderbox builds to check on port usage of the USE_PYTHON
>>>>>> variable, and
>>>>>> I noticed that devel/py-setuptools no longer builds if Python 2.4 is
>>>>>> selected.
>>>>>>
>>>>>> I'd like to restore that capability, but before I send a PR, I
>>>>>> wanted to
>>>>>> check with you first.
>>>>>>
>>>>>> Thank you,
>>>>>> Greg
>>>>>> - -- 
>>>>>> Greg Larkin
>>>>>>
>>>>>> http://www.FreeBSD.org/           - The Power To Serve
>>>>>> http://www.sourcehosting.net/     - Ready. Set. Code.
>>>>>> http://twitter.com/cpucycle/      - Follow you, follow me
>>>>>
>>>>> I'm sorry for sail in, but i think that the reason is that python24 is
>>>>> reached it's EOL long time ago. Actually the only supported python
>>>>> releases atm according to python.org are - 2.7.2 and 3.2.1, and
>>>>> developers highly encourages the users to move to this versions.
>>>>>
>>>>> 2.5 and 2.6 are in security-fix-only mode, there will be no ANY
>>>>> releases
>>>>> for this branches after October 2011 and October 2013 respectively,
>>>>> while 2.4 does not get security-fixes even.
>>>>>
>>>>> There is also this answer from Martin in this pr:
>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526:
>>>>>
>>>>> python24 goes to the end of month, this port is on the todo for
>>>>> removal
>>>>>
>>>>
>>>> Hi Ruslan,
>>>
>>> Hi Greg
>>>
>>>>
>>>> Ok, thank you for the explanation.  Shall I mark python24 for removal
>>>> from the tree or file a PR for python@ to do it?
>>>
>>> It's not so easy actually, since we have many ports in the tree that
>>> still depend on 2.4 (notably all that zope/plone stuff) and i believe it
>>> was the reason why python24 still not be removed in the first place.
>>> I do some work about eliminating python24 usage in the tree (yesterdays
>>> py-pysqlite2x stuff - one of it), but it's not that fast. I also working
>>> on porting zope2.13/plone4 (that supports python 2.6 and 2.7) and i'm
>>> planing to finish it this weekend after proper testing. After that we
>>> can deprecate/remove existing zope/plone (not longer supported
>>> upstream).
>>
>> Ok, it's a bigger job than I realized!
>>
>>>
>>>>
>>>> FYI, I have been running tinderbox builds with PYTHON_VERSION and
>>>> PYTHON_DEFAULT_VERSION set to python2.4, python2.5, etc. to find out if
>>>> ports with USE_PYTHON=yes need to be constrained a bit more.
>>>
>>> Yes, there is a lot of work. We have USE_PYTHON with bogus values like
>>> 1.5+, 1.6+, 2.0+ etc :). And most of python ports will not work with
>>> python3x so they should be constrained with -2.7 too.
>>
>> Do you think it's helpful then to run these builds with different Python
>> versions enforced?  I thought that getting the version ranges in the
>> USE_PYTHON variable tightened up might help reduce the number of folks
>> who run into build problems.  I would like to do the same thing with
>> Perl, GCC, and others.
> 
> I, personally, believe that this almost can't help to identify
> version-specific problems, since commonly there is almost no build
> problems on different python versions (it's rarely when setup.py
> actually checking which python version it was run with). The problems
> arises on runtime stage, when apps starting to import modules, that may
> not exist in this particular python version or that installed by missing
> dependencies, etc. Such problems may be identified only with manual
> checking/greping/app docs reading. But this is just my point.
> You'd better to ask Martin - he is committer that skilled with python
> stuff in ports, and i'm not proper person to take responsibility for
> decisions like that :). I just can to sound my point on this. However,
> it definitely will help to identify gcc version-specific build problems.

I have found some build problems with ports that use USE_PYTHON=yes
instead of restricting it to a specific version, e.g.

> copying build/lib/mpd.py -> /usr/local/lib/python2.4/site-packages
> byte-compiling /usr/local/lib/python2.4/site-packages/mpd.py to mpd.pyc
>   File "/usr/local/lib/python2.4/site-packages/mpd.py", line 293
>     yield retval()
> SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause
> writing byte-compilation script '/tmp/tmpoLWlQC.py'
> /usr/local/bin/python2.4 -O /tmp/tmpoLWlQC.py
>   File "/usr/local/lib/python2.4/site-packages/mpd.py", line 293
>     yield retval()
> SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause
> removing /tmp/tmpoLWlQC.py
> /bin/mkdir -p /usr/local/share/doc/py24-mpd

Admittedly, this particular error was encountered while using Python 2.4
as the default version, but I plan to run builds with all of the other
versions looking for similar build problems.

Regards,
Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5eUsQACgkQ0sRouByUApAF1ACdE1AbE5ARnnL8n7eVLbC9iQeW
qH0An2UQChPo0ezhPBsIt5a3PmlGYe1D
=4OEZ
-----END PGP SIGNATURE-----