> On 27 Dec 2016, at 19:36, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > >> On 21 Dec 2016, at 00:02, Barry Scott <ba...@barrys-emacs.org >> <mailto:ba...@barrys-emacs.org>> wrote: >> >>> >>> On 18 Dec 2016, at 20:39, Ronald Oussoren <ronaldousso...@mac.com >>> <mailto:ronaldousso...@mac.com>> wrote: >>> >>> Hi, >>> >>> I had hoped to release a new version of py2app today, but didn’t due to >>> problems with macholib that resulted in broken application bundles. The >>> good news is that I found the cause of that breakage and reverted the patch >>> that caused it. >>> >>> I did fix a number of bugs on the tracker last week (the number of open >>> issues decreased from 94 to 72), and implemented a useful new feature: >>> support for “@loader_path” in shared libraries, which is used in wheels >>> processed with delocate >>> <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py >>> >>> <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>> >>> such as the wheels for Pillow. >>> >>> Because this is turning into a fairly large release I’d appreciate if >>> people could test the code in the repository with their applications. To >>> install first install altgraph-0.13, then install modulegraph, macholib and >>> py2app from their bitbucket repositories >>> (https://bitbucket.org/ronaldoussoren/modulegraph >>> <https://bitbucket.org/ronaldoussoren/modulegraph>, >>> https://bitbucket.org/ronaldoussoren/macholib >>> <https://bitbucket.org/ronaldoussoren/macholib> and >>> https://bitbucket.org/ronaldoussoren/py2app >>> <https://bitbucket.org/ronaldoussoren/py2app>). >>> >>> There’s still a fairly large number of open issues for py2app, but those >>> will have to wait for a later time (which hopefully be a lot sooner than >>> the time it took me to get from the previous release to this point). >>> >> >> Thanks for working on an update. I know you time is limited, however I hope >> you can comment on these questions about py2app. >> I was looking at contributing patches but found, as you did that macholib >> was very broken so gave up patching and hacked workarounds. >> >> I’m using py2app to package a couple of apps that use PyQt and pytz. >> >> I found that the resulting app has the .dylib files in the python35.zip. >> Is that correct? I had assumed that .dylib files need to be in the .app >> as files, is there a trick to run them out of the .zip file? > > That’s not supposed to happen. Are the dylibs part of a python package? If > so, are these loaded by C extensions or included as data files (for example > because ctypes is used to load the dylib)? > > A bug report on bitbucket with a sample project that demonstrates the problem > would be appraised. I cannot promise that I’ll promptly fix the issue, but a > sample project would make fixing this a lot easier.
Will do. It looks like for PyQt5 you put the .so files you find in to the app ion Contents/Resources/lib/python3.5/lib-dynload/PyQt5/Qt.so etc. But PyQt5 will not work without a lot of other files from the packager also being files on disk. They are all in the python35.zip. > > As an aside to this: I’m considering to remove the site-packages.zip file > from the app bundle and store everything outside off zipfiles. A lot of code > works inside zipfiles, but there are too many exceptions and with the > transition from eggs to wheels even less packages will care to document > whether or not they work with their code in zipfiles. If you dropped the ZIP, or a option to not use it, then this bug wold be fixed. Otherwise I have to tell py2app that PyQt5 must be on disk not in ZIP. >> >> I have been copying in the PyQt .dylib, plugins etc into the .app with >> a script that adds these in Contents/Frameworks etc after fixing up the >> RPATHs. >> >> For pytz to work in a py2app .app pkg_resources needs to work and it >> does not. Is this a known issue? I worked around it with a stub pkg_resources >> package that reached into the python35.zip and pulled out the zoneinfo files. > > I have an issue about copying enough information into the application to > ensure pkg_resources.require works, but haven’t gotten around to doing the > work for that because I don’t need the feature myself. > > AFAIK pkg_resources should work for accessing datafiles though. Could you > file a bug for the pytz problem on py2app’s tracker? > I also see pkg_resources broken and ship a workaround: https://github.com/barry-scott/scm-workbench/blob/master/Source/Common/wb_date.py <https://github.com/barry-scott/scm-workbench/blob/master/Source/Common/wb_date.py> >> >> It seems that py2app will package up all the files in a package, not just the >> .py files. Is that the algorithm that is used? > > That’s correct. All files in the directory of a python package are assumed to > be important. > > BTW. None of these fixes will be in the next release of py2app, but I really > hope to find a way to do more py2app maintenance next year (instead of > basically just doing so during vacations). I guess all the py2app related repo’s are working now. (You fixed a show stopper in macho lib recently). I’ll look to shipping you patches with the bug reports. I have experience with type of python packaging software, but for Linux and windows. Barry
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
