Among other things, this would give us subprocess, which would simplify the matter of creating new processes in Python. (We'd still need killableprocess for adding the crucial API for killing processes, but that's a minor hurdle compared to writing process code using at least two different process abstractions.) Bug 418009's patch, followup fix, and followup followup fix are examples of the problems this causes.

Can we require 2.4 on linux/mac and 2.5 on Windows? MozillaBuild already comes with 2.5, but linux distros have all kinds of python and I don't particularly want to require 2.5 there. I'm pretty sure we can have a standard API based on subprocess/killableprocess that works with 2.5/win 2.4/maclinux

Don't distros usually dump python2.5 in a separate package if that's necessary? MacPorts does that, certainly, and requiring someone to put something in their mozconfigs isn't that big a deal. It's not just the libraries that make Python 2.5 desirable, it's being able to use the same language and same features everywhere -- array comprehensions come to mind as one such feature that you have to actively remember not to use if we're going to split our requirements this way. I'd very much prefer the exact same version of the language everywhere, and I'm sure people writing Python scripts in the tree who happen to be on systems with 2.5 would agree that it's more pain to remember to test with a version that's not the default on their system in addition to whatever the default is.

Per IRC discussion, we're comfortable requiring 2.4, and 2.5 on Windows. Scratchbox ships with 2.3 by default, but ships 2.4 as python2.4. OS X 10.4 ships with 2.3 by default, but 2.4/2.5 are easily installable via darwinports (which you need to use to get other build dependencies anyway). We only officially support MozillaBuild on Windows, which ships with 2.5, and Waldo thinks 2.5-isms have crept into the Windows paths of our Python code anyway, so we might as well make that requirement explicit. We could make life slightly easier for the scratchbox folks by changing the check to be something like: AC_PATH_PROGS(PYTHON, $PYTHON python2.5 python2.4 python) but it's not a requirement.

Pretty simple test.

(In reply to comment #3) > We could make life slightly easier for the scratchbox folks by changing the > check to be something like: > AC_PATH_PROGS(PYTHON, $PYTHON python2.5 python2.4 python) Mind throwing that in to the current patch? Would save us some trouble...

Will do, I forgot about that.

Pushed (with the scratchbox-assistance change): http://hg.mozilla.org/mozilla-central/rev/96956634349c

I backed this out because it broke the Mobile build, because Scratchbox in fact only ships 2.3 by default. I'm going to file a RelEng bug to get the Mobile tinderbox updated, and we'll just have to put it in the build setup documentation.

I'll check this back in soon, since the tinderboxes all got updated.

Re-pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/ad1cb31760d0

I don't know what the situation was a year ago, but current python releases are: { http://www.python.org/download/releases/ 2.3.5-2.3.7: security-fix-only mode 2.4.4-2.4.6: same 2.5.4-(fut): same 2.6.1 : bugfix-only mode 3.0.1 : same 3.1 : current version } Thus, moving away from 2.3 (and earlier) is good :-) Then, what about a plan for followups ? To 2.5: to have the same on all platforms, as written in some previous comments. To 2.6: later?

Why do we need further plans? 2.4+ solves our current problems.

(In reply to comment #13) I was referring to comment 2 then using a supported version just seems good.

Comment on attachment 371499 [details] [diff] [review] require Python 2.4, 2.5 on Windows HOST [Checkin: Comment 25] >- HOST_AR_FLAGS='-NOLOGO -OUT:"$@"' >+ HOST_AR_FLAGS='-NOLOGO -OUT:$@' Whoops. Sorry about that. Remind me not to check it in ;-)

this breaks scratchbox builds...

So update the docs. RelEng updated Python in Scratchbox on all the build machines.

Comment on attachment 371499 [details] [diff] [review] require Python 2.4, 2.5 on Windows HOST [Checkin: Comment 25] - HOST_AR_FLAGS='-NOLOGO -OUT:"$@"' + HOST_AR_FLAGS='-NOLOGO -OUT:$@' Unrelated change? r=me otherwise.

Comment on attachment 371499 [details] [diff] [review] require Python 2.4, 2.5 on Windows HOST [Checkin: Comment 25] Pushed changeset 3e3a7373a3d0 to mozilla-central.

Can this patch also be landed on mozilla-1.9.1? It would let us simplify some mobile fennec unittest work, see details in bug#462889 (comment#21).

Why do you need it? It just sets the minimum version, and shouldn't affect the release systems at all.

(In reply to comment #21) > Can this patch also be landed on mozilla-1.9.1? It would let us simplify some > mobile fennec unittest work, see details in bug#462889 (comment#21). (In reply to comment #22) > Why do you need it? It just sets the minimum version, and shouldn't affect the > release systems at all. Inside scratchbox, /usr/bin/python is 2.3, so we want to look for 2.5 first. If this patch is landed on the 1.9.1 branch, then it will simplify a little what aki has to do in bug#462889... see attachment and recent comments there for more details. Does that help clarify?

The patches here don't include it, but Ted changed MOZ_PATH_PROGS to check for python2.5 when he pushed them: http://hg.mozilla.org/mozilla-central/rev/ad1cb31760d0#l24

(In reply to comment #20) > (From update of attachment 371499 [details] [diff] [review]) > Pushed changeset 3e3a7373a3d0 to mozilla-central. Correct changeset is: http://hg.mozilla.org/mozilla-central/rev/0611a19fee9d Followup to bug 427750 to check for Python 2.5 only when building on Windows as a host

PYTHON_VERSION check in m-c should be enough.

Comment on attachment 427024 [details] [diff] [review] (Cv1-CC) Port (the useful part of) it to comm-central [Checkin: Comment 28 & 37] I am partial to having the ver check here; but its not a requirement; I'll check with KaiRo if its worthwhile [later] no need to do it on my preference.

Comment on attachment 427024 [details] [diff] [review] (Cv1-CC) Port (the useful part of) it to comm-central [Checkin: Comment 28 & 37] http://hg.mozilla.org/comm-central/rev/4e74b1e6e94c

In the future, please file new bugs instead of adding patches to bugs that have been closed for many months.

"approval1.9.1.9=?": Zero risk, build config only. To fix bug 548670.

Comment on attachment 429080 [details] [diff] [review] (Dv1-191) Copy it to m-1.9.1 too [Checkin: Comment 33] a1919=beltzner, but please do as Ted suggests next time

Comment on attachment 427024 [details] [diff] [review] (Cv1-CC) Port (the useful part of) it to comm-central [Checkin: Comment 28 & 37] Looking for "approval-seamonkey2.0.4=?" actually.

Comment on attachment 429080 [details] [diff] [review] (Dv1-191) Copy it to m-1.9.1 too [Checkin: Comment 33] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5b9590ed573d Sorry, I pushed with my name...

(In reply to comment #31) > please do as Ted suggests next time I'd be happy to use the hundreds of bugs that someone would file to deal with http://dev.seamonkey.at/?d=x&i=mozilla&m=c ... :-|

Just because someone isn't going to file your bugs for you doesn't mean you can co-opt mine. I'm fine with you reusing my bugs when they're still open, but please don't dredge up bugs that have been closed for a long time. Feel free to file one big bug for all your work, I don't care.

Comment on attachment 427024 [details] [diff] [review] (Cv1-CC) Port (the useful part of) it to comm-central [Checkin: Comment 28 & 37] a-sm2.0.4=me

Comment on attachment 427024 [details] [diff] [review] (Cv1-CC) Port (the useful part of) it to comm-central [Checkin: Comment 28 & 37] http://hg.mozilla.org/releases/comm-1.9.1/rev/24075bb298ee

(In reply to comment #35) > Feel free to file one big bug for all your work, I don't care. I'll do ... and just get complains about that again :-[