On Feb 9, 2006, at 3:56 PM, Bill Janssen wrote: >> If we ignore the vendor's interpreter then our documentation becomes >> MUCH simpler as there will be one -- and preferably only one -- way >> to do it: install a Python interpreter that is recent and can run the >> full scope of Python applications. > > I think I'm almost convinced on this point, save for the problem of > /usr/bin/python and the default PATH. > >> If we make >> the proposed PATH change script to the installer, we can ignore the >> system Python just as easily as we could if it wasn't there at all. > > It is extremely difficult (almost impossible) to make such scripts > work properly on Unix, with the variety of shells and environments > that people use.
This is practice, not theory. Only a small subset of the target audience knows what they're doing wrt PATH and .profile (or whatever is appropriate). DarwinPorts has a simple 99.9% solution in their postflight script: check if /opt/local/bin is in the path, if not, then append a line to their .cshrc if their SHELL is *csh and append a line to their .profile if their SHELL is *sh. >> There's little good reason for us to petition for its removal, and >> there's good reason for them to keep it there: they use it. > > If they shipped, instead, the current version of MacPython, would that > make the issue moot? That is, would you still "insist" on an upgrade > before a user could use Python? Could a Mac ever ship with an > acceptable pre-installed Python? If not, perhaps the solution for > Apple is to move /usr/bin/python to some other spot, like > /usr/libexec/, or some such place. The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig