> On 21 Dec 2016, at 00:02, Barry Scott <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.
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.
>
> 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?
>
> 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).
Ronald
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
