[Pythonmac-SIG] Private frameworks - BINGO!

[Bob Ippolito]

I don't think this is a showstopper at all...

You have full control over all this stuff for post-startup dynamic 
linking..  It's trivial for python to stuff whatever it needs to stuff 
into DYLD_* environment variables when it's bootstrapping the 
interpreter.. python surely can figure out where its own framework is if 
it started up correctly.  I really think this is a non-issue, you just 
have to make sure python itself starts, because we've already 
demonstrated that if the "otool path" is incorrect it'll search through 
the default framework paths (or, if documentation serves us correctly, 
whatever they're overrided with via the environment).

-bob

On Friday, August 23, 2002, at 07:25 PM, Jack Jansen wrote:

>
> On vrijdag, augustus 23, 2002, at 11:16 , Tony Lownds wrote:
>> The shared modules in lib-dynload also refer back to the framework. 
>> When trying things out do an "import array"...
>
> Hmm, that could be showstopper...
>
> They refer back to the framework because you can't specify a framework 
> as the bundle_loader (which is what I really wanted to do). Bummer...
>
> Unless someone has a real bright idea (and don't even think of 
> suggesting we link extensions with a flat namespace:-) I think we have 
> to live with the framework living in one of the standard locations. It 
> is probably also the end of any aspirations at BuildApplication for 
> OSX-Python.
>
> [thinks a while]
> That is: what would happen if the shared modules also referred to the 
> framework with the @executable cookie? If by any chance the cookie 
> would be replaced by the pathname of the *hosting* application (i.e. 
> python) then it might still work...
>
> Anyone feels like trying this out?