On 4 Apr, 2013, at 17:01, Nat Echols nathaniel.ech...@gmail.com wrote:
On Thu, Apr 4, 2013 at 5:46 AM, Ronald Oussoren ronaldousso...@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
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
