[Pythonmac-SIG] Doing it differently: Module management / installation

[Bill Bumgarner]

(I have been following the 'Let's do it completely different!' thread 
with quite a bit of interest -- this is a direction that I have long 
felt that Python on OS X should take.   I'll comment more on that 
later.)

On Wednesday, October 23, 2002, at 04:44 AM, 
pythonmac-sig-request@python.org wrote:
> Maybe then what is needed is to have a Applications/Python folder, and
> have an "Extensions" folder inside that (or Lib/site-packages, etc.)
> that people can drop modules into. That way, Mac users can add/install
> modules without having to interact with the Terminal or Unix 
> filesystem.

In general, there should be no requirement that anything be installed 
in /Applications.   /Applications is Apple's domain and third parties 
shouldn't touch it (I can't begin to tell you how much it offends my 
security minded and multi-user aware self when a third party insists on 
scribbling in /Applications/... many many reasons why that is just 
stupid).   Furthermore, requiring anything to be dropped in 
/Applications prevents any user who does not have admin rights from 
installing the software-- basically, it eliminates the installation of 
the software by any student using a lab computer unless the network 
admins sanction it.

In talking extensions -- things that are not standalone applications -- 
it should be modeled after the "standards" set forth by Apple.   That 
is, there should be a set of search paths that are added to sys.path.  
Most likely:

~/Library/Python/Extensions
~/Developer/Python/Extensions
/Library/Python/Extensions
/Network/Library/Python/Extensions
/Network/Developer/Python/Extensions
/System/Library/Python/Extensions
/Developer/Python/Extensions

API is even provided to generate a list of all Library locations.  
This...

   NSLog(@"%@", 
NSSearchPathForDirectoriesInDomains(NSAllLibrariesDirectory, 
NSAllDomainsMask, NO));

... spews this ...

2002-10-23 09:44:49.917 barf[17140] <CFArray 0x67280 [0xa01303fc]>{type 
= immutable, count = 8, values = (
	0 : <CFString 0x670d0 [0xa01303fc]>{contents = "~/Library"}
	1 : <CFString 0x670f0 [0xa01303fc]>{contents = "~/Developer"}
	2 : <CFString 0x67110 [0xa01303fc]>{contents = "/Library"}
	3 : <CFString 0x67130 [0xa01303fc]>{contents = "/Developer"}
	4 : <CFString 0x67150 [0xa01303fc]>{contents = "/Network/Library"}
	5 : <CFString 0x65bb0 [0xa01303fc]>{contents = "/Network/Developer"}
	6 : <CFString 0x671a0 [0xa01303fc]>{contents = "/System/Library"}
	7 : <CFString 0x671c0 [0xa01303fc]>{contents = "/Developer"}
)}

... and it is a short step to append Python/Extensions to each to come 
up with the paths.  The result can be prepended to sys.path.

The end result is a Python environment that works well for the 
single-user, single-machine mac traditionalist (though, keep in mind, 
there is not a single OS X box on the planet that is really 
single-user!) while scaling cleanly into multi-user, fully networked 
accounts/filesystems, administrator controlled environments.

> I think that applets also should be able to have any necessary modules
> above and beyond what Jaguar Python provides inside the app bundle so
> that they can run on machines without MacPython installed, though. (Or
> maybe BuildApplication could provide this functionality?)

The PyObjC Project Builder template supports this now.  From the 
Project Builder perspective, it was a simple matter of creating a "copy 
files" build phase and copying the modules into the pyobjc/ 
subdirectory of the Resources/ directory.   At app startup, the Python 
entry point simply does....

     import sys
     import os.path
     sys.path.insert(0, os.path.join(sys.path[0], "pyobjc"))

... this makes the assumption that path[0] is the path to the app 
wrapper -- but that is a safe assumption given the way the bootstrap 
executable [including, I believe PythonLauncher] works and its 
interaction with the way Apple's app launching mechanisms work.

b.bum