[Pythonmac-SIG] What should be on sys.path for MacPython 2.3

[Bob Ippolito]

On Saturday, Apr 12, 2003, at 18:36 America/New_York, Jack Jansen wrote:

>
> On zaterdag, apr 12, 2003, at 20:28 Europe/Amsterdam, Tony Lownds  
> wrote:
>> ~/Library/Python is shorter, and there are no spaces in the path. I
>> like the idea of having a spot for more stuff, but I also think it is
>> more intuitive for ~/Library/Python/ to be in sys.path directly.
>> Directories with other purposes under ~/Library/Python won't be put
>> on the path unless there is an __init__.py file so I think it might
>> make sense NOT to append site-packages or site-python.
>
> Hmm, hmm, you have a point here (the nice and short name), but I'm not
> convinced yet that stuffing other directories in here is a good idea.
> Also, we have the version number problem, so it should at the very  
> least
> be ~/Library/Python/2.3/.

Another thing significant to note is that Apple chooses /Library/Perl  
and /System/Library/Perl nomenclature for its Perl installation (I'm  
not sure if it supports ~/Library/Perl or /Network/Library/Perl), so we  
should be allowed to do the same.  However, Perl is not compiled as a  
framework... which leaves some ambiguity in this case because Python is.

>> It would seem to be most conforming to the platform standard if the
>> order matches the framework search order:
>>
>> ~/Library/Python, /Library/Python, /Network/Library/Python,
>> /System/Library/Python
>
> I don't want to put /System/Library/Python there, I think it's a case  
> of over-generality.
> But the other three: yes, I think that would be a good idea.

I'd make it easy for the user who is compiling Python 2.3 to decide  
whether they want /System/Library/Python or not.  Whoever maintains  
Python for Apple would probably appreciate this, because that's their  
style, and we can all cross our fingers and hope that 2.3 will be  
compiled and distributed PROPERLY with OS X 10.3.X or 10.4.  All of us  
know how messed up the Python 2.2.0 that ships with OS X 10.2.X is, and  
I for one never ever want to see that sort of thing happen again.

Back to the "Perl is not a framework" issue, I think that we have some  
justification for using /System/Library/Python/VERSION as a symlink..   
We have some ambiguity as far as where the heck should Python modules  
go?  For Python to be generally useful,  you need a bunch of modules.   
If you're going to distribute an application that has a Python  
framework inside it, it's highly likely that some of those modules are  
going to be necessary.  What do we do in this case?  Here's my  
preference (pretending I'm Apple and can use /System freely):
/System/Library/Frameworks/Python.framework/Versions/VERSION/lib/ 
pythonVERSION should store all of the actual standard python modules
/System/Library/Python/VERSION should be a symlink to the above path
/Library/Python/VERSION should be the site-packages directory,  
/System/Library/Frameworks/Python.framework/Versions/VERSION/lib/ 
pythonVERSION/site-packages will symlink to this path (perhaps not  
necessary to add it to the search path?)
~/Library/Python/VERSION should be in the search path
/Network/Library/Python/VERSION should be in the search path

Basically, in this configuration, someone could just rip  
Python.framework out, stick it in an application bundle, and it should  
just work because it'll have all the standard modules it may need.   
site-packages goes to an easier to type and more intuitive path that  
can be reasonably navigated to via Finder (for drag & drop installs),  
and non-administrator users and network administrators can install  
modules into places that they have access to.

Also, does distutils support this kind of configuration?  Where users  
can install modules into some ~path, administrators can install to  
~path or /path, and network admins can install to ~path /path or  
/Network/path?  Do we need to enhance distutils, or make a mac specific  
extension to distutils for this?

-bob