bugzilla-tool should detect python < 2.5 and show a nice error message
Google has this screwy config where "python" maps to python 2.4 instead of python 2.5 on the corp image. Presumably this will go away when we migrate to snow leopard, but for now everyone who tries bugzilla-tool on a google mac gets an ugly parse error.
We could fix this via:
1. Using a different #! line, like: "#!/usr/bin/env python2.5"
2. Detecting python < 2.5 (or missing ternary operators) and show a nice error message, including even something about how to fix your Google mac. :)
3. Some other nifty hack.
Would it be hard to just support python2.4? I don't really like python's ternary syntax anyway.
If you want to detect version, you can use sys.version_info.
Solution 1 isn’t a good idea since it’ll break for folks that only have Python > 2.5.
I'm not sure how difficult it would be support 2.4. I'd have to check what other features we depend on.
For future reference, here is a case of code breaking with Python 2.5:
Maybe test-webkitpy should issue a warning if run using Python 2.6+.
Created attachment 50180 [details]
I didn't add any information about how to upgrade. Perhaps we can simply include a link to this wiki page, and include instructions there:
Let me know your preference.
Also, note that pending patches in the following two reports are required for this patch to work:
So the style bot may not work. Also marking cq- for that reason.
Comment on attachment 50180 [details]
I'm not wild about the name "patcher.py".
We've discussed the issue of python version requirements a bunch. I'm not 100% sure what the final resolution was, but this patch is just making the code print a nicer error message. If we want to support older versions of Python, we can still do that.
(In reply to comment #6)
> (From update of attachment 50180 [details])
> I'm not wild about the name "patcher.py".
Agreed. We can rename in a later patch. I mainly wanted to choose something without "webkit" in the name since it's redundant with being in webkitpy.
Naming the main lead-in file for a package main.py might be a good way to go. But that didn't quite seem to fit here since the module does more than expose a main method -- it defines a substantive class.
> We've discussed the issue of python version requirements a bunch. I'm not 100%
> sure what the final resolution was, but this patch is just making the code
> print a nicer error message. If we want to support older versions of Python,
> we can still do that.
Exactly. Hopefully we'll get clarification on that soon. I might prod the list again on Monday -- this time with an attempted summary.
Manually committed (via git svn dcommit):