[Pythonmac-SIG] My stab at a new page
Bob Ippolito
bob at redivi.com
Fri Feb 10 01:10:08 CET 2006
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
More information about the Pythonmac-SIG
mailing list