[Pythonmac-SIG] py2app failure with framework build of 2.7

[Ronald Oussoren]

On 4 Apr, 2013, at 17:01, Nat Echols <nathaniel.echols at gmail.com> wrote:

> On Thu, Apr 4, 2013 at 5:46 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>> Replying to my own post: after sending this, I read the section in the
>>> documentation about "alias mode".  This seems to work fine, and
>>> produces an app that is 50KB instead of nearly 9MB.  Since I'm running
>>> this script as part of a complicated build and installation process,
>>> and the path to the interpreter and all modules is frozen by the time
>>> I need to make my app, it would seem that alias mode should work fine
>>> for actually *deploying* my software.  Is there any drawback to doing
>>> this?
>> 
>> An alias mode build contains symlinks to the python files in your application, and is therefore not a useful way to deploy.
> 
> It's still not totally clear to me if this is really a drawback in my
> case.  The software distribution in question is a huge (~2GB) mess
> originally written for Unix systems, and the installation process is
> somewhat... inelegant.  Users have a choice of a) running a shell
> script which installs to a destination of their choice, and runs the
> py2app script at the end (after the new location is made permanent),
> or b) running a .pkg which installs in /Applications, which includes
> the pre-built .app file.  In the first case, I'm pretty certain the
> symlinks won't be a problem.  I'm not sure about the second - will
> packagemaker screw these up?  The original paths will be accurate but
> I have to move stuff around as part of the packaging process, and I
> have no idea what happens internally.

Packagemaker should't be problem here, although the build procedure might
be problematic: IIRC the app bundle contains symlinks where the target
is an absolute path, and therefore you need to create the app from
sources that are already in the final location (e.g. somewhere below /Applications).

It might be better to create a --semi-standalone, --use-sitepackages build, and
--exclude most of the code. Assuming you also install a shared library build
(either --enable-shared or --enable-framework) of Python in /Applications that 
should be fairly easy to get to work (you have to update the application's Info.plist 
to force it to look for Python in the right location, but that's the hardest part).

The primary reason I dislike using an alias build for deployment is that alias
builds are meant to be a way to speed up development and I might accidently break
the deployment usecase when I find ways to make alias builds better for
the "application development" use case.

Ronald

> 
> thanks,
> Nat