Py2app

- Issue 82: Remove debug print statement from py2app.util.LOADER that
caused problems with Python 3.

- Issue 81: Py2app now fails with an error when trying to build a bundle
for a unix-style shared library build of Python (``--enable-shared``) unless
you are using a recent enough patchlevel of python (2.7.4, 3.2.3, 3.3.1,
3.4.0, all of them are not released yet).

The build failure was added to avoid a very confusing error when trying
to start the generated application due to a bug in the way python reads
the environment (for shared library builds on Mac OS X).

- Py2app will also give an error message when the python binary does not
have a shared library (or framework) at all.

- Issue 87: Ignore '.git' and '.hg' directories while copying package data
('.svn' and 'CVS' were already ignored).

- Issue 65: the fix in 0.7 to avoid copying a symlinked library twice caused
problems for some users because only one of the file names ended up in the
application bundle. This release ensures that both names exist (one as a
symbolic name to the other).

- Issue 88: Ensure that the fix for 65 won't try to create a symlink that
points to itself. This could for example occur with homebrew, where the
exposed lib directory contains symlinks to a cellar, while type install_name
does mention the "public" lib directory::

$ ls -l /opt/homebrew/lib
...
libglib-2.0.0.dylib -> ../Cellar/glib/2.32.4/lib/libglib-2.0.0.dylib
...

$ otool -vL /opt/homebrew/lib/libglib-2.0.0.dylib
/opt/homebrew/lib/libglib-2.0.0.dylib:
/opt/homebrew/lib/libglib-2.0.0.dylib (compatibility version 3201.0.0, current version 3201.4.0)
time stamp 1 Thu Jan 1 01:00:01 1970
...

- Issue 75: Don't remove ``--dist-dir``, but only remove the old version
of the objects we're trying to build (if that exists).

This once again makes it possible to have a number of setup.py files that
build plugins into the same target folder (such as the plugins folder
of an application)

- Issue 78: Packages added using the ``--packages`` option didn't end up
on ``sys.path`` for semi-standalone applications.

Reported by Steve Strassmann

- Issue 76: Semi-standalone packages using extensions modules couldn't use
extensions unless they also used the ``--site-packages`` option (and
the extensions are in the site-packages directory).

Fixes some problems with PyQt and wxWidgets when using the system installation
of Python.

Patch by Dan Horner.

- It is currently not possible to use a subpackage ("foo.bar") in the list
of packages for the "packages" option. Py2app now explicitly checks for this
and prints an error message instead of building an application that doesn't
work.

Issue: 39

- Always include 'pkg_resources', this is needed to correctly work with
setuptools namespace packages, the __init__.py files of those contain
``__import__('pkg_resources')`` and that call isn't recognized as an import
by the bytecode scanner.

- Issue 67: py2applet didn't work with python 3 due to the use of 'raw_input'

Reported by Andrew Barnert.

- Issue 68: the "extra-scripts" feature introduced in 0.7 couldn't copy scripts
that aren't in the same directory as "setup.py".

Reported by Andrew Barnert.

- For semi-standalone applications the "lib-dynload" directory inside the
application was not on "sys.path", which resulted in launch failures
when using an extension that is not in the stdlib.

- Issue 70: application fails to launch when script uses Windows line endings

Reported by Luc Jean.

- Issue 65: generated bundle would crash when two libraries linked to the
same library using different names (one referring to the real name, the other
to a symlink).

An example if this is an application using wxWidgets when wxWidgets is installed
using homebrew.

Reported by "Bouke".

- Issue 13: It is now possible to add helper scripts to a bundle, for
example for creating a GUI that starts a helper script in the background.

This can be done by using the option "--extra-scripts", the value of which is a list
of script files (".py" or ".pyw" files).

- Smarter matplotlib recipe, it is now possible to specify which backends should
be included. Issue 44, reported by Adam Kovics.

The argument to ``--matplotlib-backends`` (or 'matplotlib_backends' in setup.py)
is a list of plugins to include. Use '-' to not include backends other than those
found by the import statement analysis, and '*' to include all backends (without
necessarily including all of matplotlib)

As an example, use ``--matplotlib-backends=wxagg`` to include just the wxagg
backend.

Default is to include the entire matplotlib package.

- The packages included by a py2app recipe weren't processed by modulegraph and
hence their dependencies were not always included.

- Fix virtualenv support: alias builds in a virtual environment failed to work.

(There are still issues with semi-standalone and alias plugin bundles in
a virtualenv environment).

- issue 18: improved PyQt and PySide support.

Py2app now has a new option named "--qt-plugins" (or "qt_plugins" in setup.py),
this option specify a list of plugins that should be included in the
application bundle. The items of the list can have a number of forms:

* "plugintype/libplugin.dylib"

Specify one particular plugin

* "plugintype/\*foo\*"

Specify one or more plugins using a glob pattern

* "plugintype"

Include all plugins of a type, equivalent to "plugintype/\*".

The plugins are copied into "Resources/qt_plugins" and py2app adds a "qt.conf"
file that points to that location for plugins.

- issue 49: package data that is a zipfile is now correctly copied into
the bundle instead of extracting the archive.

- issue 59: compile site.py to ensure that the generated bundle doesn't
change on first run.

This is nice to have in general, and essential when using code signing
because the signature will break when a new file is added after signing.

Reported by Michael McCracken.

- issue 60: recipe for "email" package was not loaded

Reported by Chris Beaumont

- issue 46: py2app no longer warns about the Qt license. We don't warn about
other possibly GPL licensed software either and py2app is not
a license-enforcement tool.

Reported by briank_in_la.

- Generated bundles always started with python optimization active
(that is, as if running as 'python -O').

- Fix issue 53: py2app would crash if a data file happened to
be a zipfile.

- py2app copies data files in the directory for a package into
the application bundle. It also did this for directories that
represent subpackages, which made it impossible to exclude
subpackages.

- added recipe for wxPython because some subpackages of wxPython
use ``__path__`` trickery that confuses modulegraph.

- recipes can now return a list of additional entries for the
'includes' list.

- rewritten the recipe for matplotlib. The recipe no longer includes
the entire package, but just the "mpl-data" directory.

WARNING: This recipe has had limited testing.

- fix mixed indentation (tabs and spaces) in argv_emulation.py,
which caused installation failures on python 3.x (issue 40)

- Issue 43: py2app now creates a symlink named "Current" in the
'Versions' directory of the embedded Python framework to comply
with a requirement for the Mac App-store.

- on some OSX releases the application receives both the
"open application" and "open documents" Apple Events during startup,
which broke an assumption in argv_emulation.py.

- py2app is more strict w.r.t. explicitly closing files, this avoids
ResourceWarnings for unclosed files.

- fix test issue with semi-standalone builds on Python 3.2

- added recipe for pyzmq

- Don't use the version information from Python.framework's Info.plist,
but use ``sys.version_info``. This fixes a build problem with EPD.

- Ignore some more files when copying package data:

- VIM swap files (``.foo.py.swp``)

- Backup files for a number of tools: ``foo.orig`` and ``foo~``

- Issue 28: the argv emulator crashes in 64-bit mode on OSX 10.5

Fixing this issue required yet another rewrite of the argv_emulator
code.

- Added option '--arch=VALUE' which can be used to select the set of
architectures for the main executable. This defaults to the set of
architectures supported by the python interpreter and can be used to
drop support for some architectures (for example when you're using a
python binary that supports both 32-bit and 64-bit code and use a
GUI library that does not yet work in 64-bit mode).

Valid values for the argument are archectures used in the list below
and the following groups of architectures:

* fat: i386, ppc

* fat3: i386, x86_64, ppc

* universal: i386, x86_64, ppc, ppc64

* intel: i386, x86_64



- Issue 32: fix crash when application uses PySide

This is partially fixed in macholib (release 1.4.3)

- The '-O' flag of py2app now defaults to the python optimization level
when using python 2.6 or later.

- Issue 31: honor optimize flag at runtime.

Until now an application bundle created by py2app would also run without
the "-O" flag, even when the user specified it should. This is now fixed.

- Issue 33: py2app's application bundle launcher now clears the environment
variable ``PYOBJC_BUNDLE_ADDRESS``, avoids a crash when using PyObjC in an
application launched from a py2app based plugin bundle.

- py2app's bundle launcher set the environment variable ``PYOBJC_BUNDLE_ADDRESS``,
this variable is now deprecated. Use ``PYOBJC_BUNDLE_ADDRESS<PID>`` instead
(replace ``<PID>`` by the process ID of the current process).

- When using the system python we now explicitly add Apple's additional packages
(like PyObjC and Twisted) to ``sys.path``.

This fixes and issue reported by Sean Robinson: py2app used to create a non-working
bundle when you used these packages because the packages didn't get included
(as intended), but were not available on ``sys.path`` either.

- Fixed the recipe for sip, which in turn ensures that PyQt4 applications
work.

As before the SIP recipe is rather crude, it will include *all* SIP-based
packages into your application bundle when it detects a module that uses
SIP.

- The 'Resources' folder is no longer on the python search path,
it contains the scripts while Python modules and packages are located
in the site-packages directory. This change is related to issue 30.

- The folder 'Resources/Python/site-packages' is no longer on the python
search path. This folder is not used by py2app itself, but might by
used by custom build scripts that wrap around py2app.

- Issue 30: py2app bundles failed to launch properly when the scriptfile
has the same name as a python package used by the application.

- Issue 15: py2app now has an option to emulate the shell environment you
get by opening a window in the Terminal.

Usage: ``python setup.py py2app --emulate-shell-environment``

This option is experimental, it is far from certain that the implementation
works on all systems.

- Issue 16: ``--argv-emulation`` now works with Python 3.x and in 64-bit
executables.

- Issue 17: py2applet script defaults 'argv_emulation' to False when your using
a 64-bit build of python, because that option is not supported on
such builds.

- py2app now clears the temporary directory in 'build' and the output directory
in 'dist' before doing anything. This avoids unwanted interactions between
results from a previous builds and the current build.

- Issue 22: py2app will give an error when the specified version is invalid,
instead of causing a crash in the generated executable.

- Issue 23: py2app failed to work when an .egg directory was implicitly added
to ``sys.path`` by setuptools and the "-O" option was used (for example
``python setup.py py2app -O2``)

- Issue 26: py2app copied the wrong executable into the application bundle
when using virtualenv with a framework build of Python.

- py2app failed to compile .xib files
(as reported on the pythonmac-sig mail-ing list).