py2app is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to py2exe. Even at this early stage, it's probably the most advanced python packaging utility out there with regard to dependency analysis. It's at a "works for me and the two other people that have tried it" stage. It's not particularly documented, and I don't have time to document it today, but you should be able to get along given the examples. Since it is very similar to py2exe in design, you can also borrow ideas from there. If you have any issues with py2app, please let me know. Provide source if possible. I'm particularly interested in problematic packages which use import tricks or in-package data files such as PIL or pygame. These two are explicitly supported by the extensible "recipe" mechanism of py2app, but there are surely others. I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things. Until a recipe is created for a particular problematic package, you may always just include it wholesale with the -p argument. Download and related links are here: http://undefined.org/python/#py2app -bob
At 04:51 PM 10/3/04 -0400, Bob Ippolito wrote:
I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things.
PEAK definitely includes data files in package directories, and the latest version of the distutils supports doing such installs directly. (PEAK uses setuptools, though, since its minimum Python version is Python 2.2.2.) I don't have a Mac, though, so I'll have to rely on your feedback regarding PEAK's buildability with py2app. There are a number of potential issues: * Current versions of Python have a broken reload() function with respect to PEP 302; PEAK uses 'reload()' to drive a "lazy import" facility that also allows setting triggers to run when modules are imported. * PEAK uses in-package data files, and expects them to be accessible as regular files. This means that even if reload() worked correctly, it would break with e.g. putting the package in a zipfile. I do plan to make this PEP 302 compatible in the near future, by checking for a __loader__ attribute with a 'get_data()' method, and using that instead of direct filesystem access, if available. * PEAK uses dynamic and lazy imports extensively, which makes it impossible to find all its imports using only bytecode analysis. An ability to specify modules or packages as part of a setup.py is a must.
On Oct 3, 2004, at 10:52 PM, Phillip J. Eby wrote:
At 04:51 PM 10/3/04 -0400, Bob Ippolito wrote:
I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things.
PEAK definitely includes data files in package directories, and the latest version of the distutils supports doing such installs directly. (PEAK uses setuptools, though, since its minimum Python version is Python 2.2.2.)
py2app is using setuptools too, supporting a minimum Python version of 2.3.0. It was MUCH MUCH simpler than using distutils directly. Additionally I borrowed the sdist script from PyObjC that ignores subversion junk.
I don't have a Mac, though, so I'll have to rely on your feedback regarding PEAK's buildability with py2app. There are a number of potential issues:
* Current versions of Python have a broken reload() function with respect to PEP 302; PEAK uses 'reload()' to drive a "lazy import" facility that also allows setting triggers to run when modules are imported.
* PEAK uses in-package data files, and expects them to be accessible as regular files. This means that even if reload() worked correctly, it would break with e.g. putting the package in a zipfile. I do plan to make this PEP 302 compatible in the near future, by checking for a __loader__ attribute with a 'get_data()' method, and using that instead of direct filesystem access, if available.
* PEAK uses dynamic and lazy imports extensively, which makes it impossible to find all its imports using only bytecode analysis. An ability to specify modules or packages as part of a setup.py is a must.
Yeah, I was pretty sure that this was the case. You simply just specify that you want to include PEAK as a package (which includes the whole package as-is, outside of the zip file). At some point I'll add a recipe that detects the presence of PEAK and makes this happen automatically, like I do for pygame, but I'm going to wait a bit until I hear about other packages so I can just do them all at once before the next release. -bob
At 11:16 PM 10/3/04 -0400, Bob Ippolito wrote:
py2app is using setuptools too, supporting a minimum Python version of 2.3.0. It was MUCH MUCH simpler than using distutils directly.
Nice to know. What parts of setuptools did you end up using? "Features", "dependencies", or just the data file stuff?
On Oct 3, 2004, at 11:51 PM, Phillip J. Eby wrote:
At 11:16 PM 10/3/04 -0400, Bob Ippolito wrote:
py2app is using setuptools too, supporting a minimum Python version of 2.3.0. It was MUCH MUCH simpler than using distutils directly.
Nice to know. What parts of setuptools did you end up using? "Features", "dependencies", or just the data file stuff?
Well, it's open source, you can look for yourself :) http://svn.red-bean.com/bob/py2app/trunk/setup.py I'm using find_packages, the package_data stuff.. maybe other stuff implicitly? I didn't read the source or documentation for setuptools, I just cut+pasted from PEAK's setup.py. I went to PEAK first because I knew it dealt with installing multiple top level packages with data files and such, and I knew these things were terribly difficult with stock distutils. "Features" will probably be useful to me in the future, but it's not something I needed for this. -bob
Does it work on Linux? Flavio On Sunday 03 October 2004 20:51, Bob Ippolito wrote:
py2app is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to py2exe.
Even at this early stage, it's probably the most advanced python packaging utility out there with regard to dependency analysis. It's at a "works for me and the two other people that have tried it" stage. It's not particularly documented, and I don't have time to document it today, but you should be able to get along given the examples. Since it is very similar to py2exe in design, you can also borrow ideas from there.
If you have any issues with py2app, please let me know. Provide source if possible. I'm particularly interested in problematic packages which use import tricks or in-package data files such as PIL or pygame. These two are explicitly supported by the extensible "recipe" mechanism of py2app, but there are surely others. I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things. Until a recipe is created for a particular problematic package, you may always just include it wholesale with the -p argument.
Download and related links are here: http://undefined.org/python/#py2app
-bob _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Oct 4, 2004, at 9:05 AM, Flávio Codeço Coelho wrote:
On Sunday 03 October 2004 20:51, Bob Ippolito wrote:
py2app is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to py2exe.
Even at this early stage, it's probably the most advanced python packaging utility out there with regard to dependency analysis. It's at a "works for me and the two other people that have tried it" stage. It's not particularly documented, and I don't have time to document it today, but you should be able to get along given the examples. Since it is very similar to py2exe in design, you can also borrow ideas from there.
If you have any issues with py2app, please let me know. Provide source if possible. I'm particularly interested in problematic packages which use import tricks or in-package data files such as PIL or pygame. These two are explicitly supported by the extensible "recipe" mechanism of py2app, but there are surely others. I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things. Until a recipe is created for a particular problematic package, you may always just include it wholesale with the -p argument.
Download and related links are here: http://undefined.org/python/#py2app
Does it work on Linux?
No, it's for Mac OS X only. Surely actually visiting the link would've been an easier way to come to that conclusion? :) -bob
participants (3)
-
Bob Ippolito -
Flávio Codeço Coelho -
Phillip J. Eby