[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