On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
For *nix, I think there is a simple way forward that is an improvement over where things stand now. For Windows, I don't think we can do much better than the status quo and for Mac OS X... I think Apple will do whatever Apple feel like doing :)
Apple will generally follow what we decide to do for the base install.
Anyway, I'd say that OSX should do the same as Unix platforms here and support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.
FYI, Ronald, the text version of your emails looses all quoting information. It would be nice if you could use standard email quoting (leading '>' characters).
P.S. I'm a bit confused about this discussion though, wouldn't adding python2 to the installation be a feature change and as such not something that can be done in a maintenance branch?
The purpose of the "no new features" rule is to prevent the situation where a piece of code written for X.X.2 fails to run on X.X.1 because it relies on a feature introduced in X.X.2. In this situation, we *already* have failures because scripts using /usr/bin/python2 that run on one distro won't run on a different distro where that symlink isn't defined. In this case I don't think the "no new features" rule can be applied blindly, because the feature has *already been introduced* by third parties. What we are attempting to do is make it *more* likely that things will work in the future. You can argue that having /usr/bin/python2 installed by 2.7.2 means that code written for 2.7.2 that relies on it won't run on a vanilla user-install of 2.7.1 or 2.7. But how likely is that scenario compared to the scenario where a script written for another distro fails to run because /usr/bin/python2 doesn't exist? I think the balance of the argument comes down in favor of making the change, personally. -- R. David Murray www.bitdance.com