Python min version bumped from 2.4+ to 2.5+

Greg Larkin glarkin at
Wed Aug 31 15:27:08 UTC 2011

Hash: SHA1

On 8/30/11 4:25 PM, Ruslan Mahmatkhanov wrote:
> Greg Larkin wrote on 31.08.2011 00:07:
>> Hash: SHA1
>> On 8/30/11 10:26 AM, Ruslan Mahmatkhanov wrote:
>>> Greg Larkin wrote on 30.08.2011 17:56:
>>>> Hash: SHA1
>>>> On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote:
>>>>> Greg Larkin wrote on 30.08.2011 17:05:
>>>>>> Hash: SHA1
>>>>>> Hi Martin,
>>>>>> I have a question about a commit you made in February 2011:
>>>>>> 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
>>>>>>           - The Power To Serve
>>>>>>     - Ready. Set. Code.
>>>>>>      - 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 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:
>>>>> 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
> 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/ -> /usr/local/lib/python2.4/site-packages
> byte-compiling /usr/local/lib/python2.4/site-packages/ to mpd.pyc
>   File "/usr/local/lib/python2.4/site-packages/", line 293
>     yield retval()
> SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause
> writing byte-compilation script '/tmp/'
> /usr/local/bin/python2.4 -O /tmp/
>   File "/usr/local/lib/python2.4/site-packages/", line 293
>     yield retval()
> SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause
> removing /tmp/
> /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.

Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-ports mailing list