Hi list, nice to see that py2app keeps on going and it gets better day by day. :)
I'd like to point out a problem I've come accross recently. I've looked
up the web and found no info about it (BTW, undefined.org refers to a
py2app Trac instance I've not been able to find). This mail looks
longish because i includes some text snippets.
I'm packaging a semi-standalone Python app which uses and includes PyQt.
These are the options for py2app::
setup_args['app'] = ['main_application_script.py']
setup_args['options'] = dict(
py2app=dict(
# Do not include system or vendor Python.
semi_standalone=True,
argv_emulation=True,
iconfile='application_icons.icns',
# Use the following system packages, do not include them.
site_packages=True,
excludes=['foo', 'bar'],
)
)
(Where none of the excluded packages is PyQt.) When investigating the
app directory, everything seems to be in place (the ``qt.so`` file, the
``libqt.3.dylib``, the archived modules...); however, when running the
app, I get this error:
MyApp Error
MyApp Error
An unexpected error has occurred during execution of the main script
ImportError:
'/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/qt.so'
not found
In the first place, it looks like it's trying to load the PyQt *on the
system* instead of that in the app dir. Then, it's not using the right
dir (``qt.so`` it's right under ``site-packages``), which makes some
sense to me since ``Contents/Resources/lib/python2.5/lib-dynload/qt.so``
is its path under the app dir.
Maybe that is a meditated design decision, but I strongly think that
apps should look for their own versions of libraries before using the
system one, since they may carry specially tailored versions (but I may
be wrong).
Based on that premise, I hacked ``_run()`` from ``__boot__.py`` to check
if the needed path was there but it had a lower precedence than the
system one, and these are the paths in ``sys.path`` I got::
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c5-py2.5.egg
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bdist_mpkg-0.4.3-py2.5.egg
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/py2app-0.3.6-py2.5.egg
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/macholib-1.1-py2.5.egg
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/modulegraph-0.7-py2.5.egg
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/altgraph-0.6.7-py2.5.egg
/path_to.app/Contents/Resources
/path_to.app/Contents/Resources
/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload
/path_to.app/Contents/Resources/lib/python2.5/site-packages.zip
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Numeric
/Users/ivan/Library/Python/2.5/site-packages
/path_to.app/Contents/Resources/Python/site-packages
I.e. none of them the place where the ``qt.so`` in the app dir is to be
found, so I hacked the following into ``_run()`` of ``__boot__.py``::
sys.path.insert(0,
'/path_to.app/Contents/Resources/lib/python2.5/lib-dynload')
Now running the app resulted in an application crash form regarding an
EXC_BAD_ACCESS error in ``libqt.3.dylib``. Since I suspected it was
still using the system libs (though running ``otool -L qt.so`` shows a
ref to [EMAIL PROTECTED]/../Frameworks/libqt.3.dylib``), I got the
dylib out of my ``/usr/local/lib``. Then the app ran flawlessly.
In short, I think there are three problems here with semi-standalone
apps using extensions:
1. The ``lib-dynload`` directory is not added to the path.
2. As a result, included extensions have lower precedence over system
ones (i.e. when adding the previous path it should have a higher
precedence).
3. Even when using the included extensions, those don't use included
libraries if these are also in the system (this may be harder to fix).
I may also be getting the following all wrong, but I suspect that in
semi-stadalone apps the included paths should have precedence over
system ones in ``sys.path``.
Well, I think that's all. Sorry for not being more synthetic, I try to
do my best. :) Has anyone here experienced the same problems? Have you
gotten to fix them? I'm particularly interested on your opinion about
path precedence and possible solutions for point 3. If you need more
information, don't hesitate to ask.
Thank you and best regards,
::
Ivan Vilata i Balaguer >qo< http://www.carabos.com/
Cárabos Coop. V. V V Enjoy Data
""
signature.asc
Description: Digital signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
