Re: [Pyobjc-dev] 0.9

[Tony L. <to...@lo...>]

>  > 3. Its not hard to package the modules in a subdirectory, using .pth
>>  files in /usr/lib/site-packages and with minimal extra code in
>>  bin-python-main.m.
>
>Yes, distutils supports this easily. I've used it myself and I know
>NumPy does it, too. If we choose to do this I volunteer to patch
>setup.py. Note that this makes upgrading harder (once), as you probably
>need to manually delete the modules from the "old" place.
>
>>  Hmm, and some extra code in bundlebuilder.py too, I think.
>
>Hm, I can't see why. Can you elaborate?

When I mentioned the need for extra code, I was thinking about 
including PyObjC in the application bundle. As it turns out putting 
the PyObjC directory + the PyObjC.pth into 
SomeApp.app/Contents/Resources/ "just works".

The reason it works feels coincidental. In both app wrappers 
(bundlebuilder's and bin-python-main.m) the 
SomeApp.app/Contents/Resources/ directory is added to the path by 
setting the PYTHONPATH environment variable and then exec'ing python. 
Python runs site.py, which scans for .pth files, and then the user 
code. If some other app wrapper is devised, and if that app wrapper 
modifies the path by sys.path, then those .pth files will no longer 
work.

This is all academic now, but it would be nice to guarantee that any 
new app wrappers
A) add SomeApp.app/Contents/Resources to the path
B) honor .pth files in SomeApp.app/Contents/Resources

-Tony