The bundlebuilder command-line argument --lib is supposed to be able to include frameworks in the resulting Mac app. Unfortunately, the aliases in the resulting framework copy are all broken.

For an example of this, use --lib to include Tcl.framework and then look through the framework in the resulting application package. Frameworks normally have quite a few handy aliases (such as .../Versions/Current) and all the aliases I tried were broken.

I'm not entirely sure if this actually breaks anything. The one app I've managed to build with standalone=True and use of --lib to include the Tk and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk frameworks installed) but fails with "True undefined" on another Mac running Jaguar that I happened to have handy.

This 2nd problem may be a separate bug or user error on my part. I'm not yet sure.

Logged In: YES 
user_id=45365

I cannot repeat this, neither with 2.4a1 nor with 2.3: I always get 
symlinks where they are expected. I tried the following command line 
(with test.py being a simple hello world script), on MacOS 10.3.4 with 
apple-installed Python:

/usr/bin/python /System/Library/Frameworks/Python.framework/
Versions/2.3/lib/python2.3/plat-mac/bundlebuilder.py -m test.py --lib /
Library/Frameworks/Tcl.framework build

and I got symlinks just fine. Feel free to reopen the bug report if you 
have more info.

Logged In: YES 
user_id=431773

I see. I also can follow the links using the unix command line. However, I 
cannot follow them using Finder. The links in the original packages *can* be 
followed in Finder, which is why I thought things were seriously broken.

So there is a bug in bundlebuilder (or it is exposing a bug in Finder), but its 
more cosmetic than functional. Still...it'd be nice to have normal Finder 
navigation work if the problem is fixable.

Logged In: YES 
user_id=45365

That's weird... Could it be that the original has symlinks that somehow 
double as aliases (symlinks with a resource fork??!?)?

Any ideas?