Py2app

- py2app failed to copy the iconfile into application bundle
(reported by Russel Owen)

- py2app failed to copy resources and data files as well
(the ``resource`` key in the py2ap options dictionary and
the ``data_files`` argument to the setup function).

Issue 19, reported by bryon(at)spideroak.com.

- py2app failed to build application bundles when using virtualenv
due to assumptions about the relation between ``sys.prefix`` and
``sys.executable``.

Report and fix by Erik van Zijst.

- Ensure that the 'examples' directory is included in the source
archive

Bugfixes:

- py2app failed to build the bundle when python package contained
a zipfile with data.

This version solves most of that problem using a rough
workaround (the issue is fixed when the filename ends with '.zip').

- The code that recreates the stub executables when they are
older than the source code now uses ``xcode-select`` to
find the root of SDKs.

This makes it possible to recreate these executables on machines
where both Xcode 3 and Xcode 4 are installed and Xcode 3 is
the default Xcode.

- The stub executables were regenerated using Xcode 3

As a word of warning: Xcode 4 cannot be used to rebuild the
stub executables, in particular not those that have support
for the PPC architecture.

- Don't rebuild the stub executables automatically, that's
unsafe with Xcode 4 and could trigger accidentally when
files are installed in a different order than expected.

- Small tweaks to the testsuite to ensure that they work
on systems with both Xcode3 and Xcode4 (Xcode3 must be
the selected version).

- Better cleanup in the testsuite when ``setupClass`` fails.

Features:

- it is now possible to specify which python distributions must
be available when building the bundle by using the
"install_requires" argument of the ``setup()`` function::

setup(

...
install_requires = [
"pyobjc == 2.2"
],
)

- py2app can now package namespace packages that were installed
using `pip <http://pypi.python.org/pypi/pip>` or the
setuptools install option ``--single-version-externally-managed``.

- the bundle template now supports python3, based on a patch
by Virgil Dupras.

- alias builds no longer use Carbon Aliases and therefore are
supported with python3 as well (patch by Virgil Dupras)

- argv emulation doesn't work in python 3, this release
will tell you abou this instead of silently failing to
build a working bundle.

- add support for custom URLs to the argv emulation code
(patch by Brendan Simon).

You will have to add a "CFBundleURLTypes" key to your Info.plist to
use this, the argv emulation code will ensure that the URL
to open will end up in ``sys.argv``.

- ``py2app.util`` contains a number of functions that are now
deprecated an will be removed in a future version, specifically:
``os_path_islink``, ``os_path_isdir``, ``path_to_zip``,
``get_zip_data``, ``get_mtime``, and ``os_readlink``.

- The module ``py2app.simpleio`` no longer exists, and should never
have been in the repository (it was part of a failed rewrite of
the I/O layer).

Bug fixes:

- fix problem with symlinks in copied framework, as reported
by Dan Ross.

- py2applet didn't work in python 3.x.

- The ``--alias`` option didn't work when building a plugin
bundle (issue 10, fix by Virgil Dupras)

- Avoid copying the __pycache__ directory in python versions
that implement PEP 3147 (Python 3.2 and later)

- App bundles with Python 3 now work when the application is
stored in a directory with non-ASCII characters in the full
name.

- Do not compile ``.nib`` files, it is not strictly needed and
breaks PyObjC projects that still use the NibClassBuilder code.

- Better error messages when trying to include a non-existing
file as a resource.

- Don't drop into PDB when an exception occurs.

- Issue 5: Avoid a possible stack overflow in the bundle executable

- Issue 9: Work with python 3.2

- Fix build issues with python 2.5 (due to usage of too modern distutils
command subclasses)

- The source distribution didn't include all files that needed to be
it ever since switching to mercurial, I've added a MANIFEST.in
file rather than relying on setuptool's autoguessing of files to include.

- Bundle template works again with semi-standalone builds (such as
when using a system python), this rewrites the fix for issue 10
mentioned earlier.

- Ensure py2app works correctly when the sources are located in a
directory with non-ascii characters in its name.

Bug fixes:

- Ensure that the right stub executable gets found when using
the system python 2.5

Bug fixes:

- Ensure stub executables get included in the egg files

- Fix name of the bundletemplate stub executable for 32-bit builds

----------

py2app 0.5 is a minor feature release.

Features:

- Add support for the ``--with-framework-name`` option of Python's
configure script, that is: py2app now also works when the Python
framework is not named 'Python.framework'.

- Add support for various build flavours of Python (32bit, 3-way, ...)

- py2app now actually works for me (ronaldoussorenmac.com) with a
python interpreter in a virtualenv environment.

- Experimental support for python 3

Bug fixes:

- Fix recipe for matplotlib: that recipe caused an exception with
current versions of matplotlib and pytz.

- Use modern API's in the alias-build bootstrap code, without
this 'py2app -A' will result in broken bundles on a 64-bit build
of Python.
(Patch contributed by James R Eagan)

- Try both 'import Image' and 'from PIL import Image' in the PIL
recipe.
(Patch contributed by Christopher Barker)

- The stub executable now works for 64-bit application bundles

- (Lowlevel) The application stub was rewritten to use
``dlopen`` instead of ``dyld`` APIs. This removes deprecation
warnings during compilation.