[Pythonmac-SIG] [Pyobjc-dev] py2app release delayed

[Ronald Oussoren]

> On 21 Dec 2016, at 00:02, Barry Scott <barry at barrys-emacs.org> wrote:
> 
>> 
>> On 18 Dec 2016, at 20:39, Ronald Oussoren <ronaldoussoren at mac.com <mailto:ronaldoussoren at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161227/8257854d/attachment.html>