Greg Larkin wrote on 31.08.2011 19:27:
Hi Martin,
I have a question about a commit you made in February 2011:
http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@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
Ok, this particular error is well known and 24-specific:
http://docs.python.org/reference/simple_stmts.html
"""
As of Python version 2.5, the yield statement is now allowed in the try
clause of a try ... finally construct. If the generator is not resumed
before it is finalized (by reaching a zero reference count or by being
garbage collected), the generator-iterator’s close() method will be
called, allowing any pending finally clauses to execute.
"""
I checked the docs, i checked the code for audio/py-mpd - there is
nothing about python versions. Authors just not assumed that anybody
will try to run this code with 2.4. So may be it has the point to build
such ports to check them. But i'd rather concentrate on eliminating
explicit 24-specific consumers so we can deprecate lang/python24 to
avoid such situations in principle.
And however, now we know that the left edge for SUE_PYTHON for this port
would be 2.5+, but what about the right edge? Even if it will builds
successfully with 3.x in tinderbox run, who can guarantee that it will
RUN with 3.x?
--
Regards,
Ruslan
Tinderboxing kills... the drives.
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
