Change Log for SetupHelper Version 0.4.4

:Author:        Peter A. Donis
:Last Updated:  07 December 2009

Version 0.4.4
-------------

- Added correct detection of the
  ``install_scripts`` directory used by
  distutils, to ensure that the right
  post-install scripts are run even if there
  are multiple copies on your path.

Version 0.4.3
-------------

- Switched to ``itertools`` functions where
  applicable.

- Eliminated generator expressions in favor
  of list comprehensions and ``for`` loops
  so code will run on Python versions < 2.4.

Version 0.4.2
-------------

- Fixed code for processing self-executing
  archives (e.g., EXE files) so that no
  attempt is made to "unpack" them, and they
  are only executed if the setup command is
  ``install``.

Version 0.4.1
-------------

- Added option to have the ``__start_line__``
  and/or ``__end_line__`` variables be line
  numbers instead of line contents; negative
  line numbers count from the end of the
  README file.

Version 0.4
-----------

- Added ``setuphelper`` script to enable
  SetupHelper to be used as an installer;
  script assumes each command line argument
  is a package name and tries to download
  and install it as if it were in your
  ``requires`` list. (The ``--use-setuptools``
  or ``-s`` command line option is provided
  to allow use of setuptools' ``easy_install``
  functionality for this.)

- Removed hard dependency on ``ez_setup.py``
  when setuptools is in use; if it's present,
  it will be used to ensure that setuptools
  is present, but if not, SetupHelper will
  assume that setuptools has been installed
  by other means and go on from there.

- Refactored the ``SetupHelper`` class into
  multiple variable processing methods and
  added several class fields for clarity.

- Added generic test running script and a
  doctest text file.

Version 0.3.1
-------------

- Fixed bug where requirements were not being
  processed correctly when using setuptools
  (they were showing up in PKG-INFO but were
  never actually being checked for and installed).

Version 0.3
-----------

- Added full support for PyPI metadata version
  1.1; the ``requires``, ``provides``, and
  ``obsoletes`` keywords now populate metadata
  fields even in Python versions < 2.5. Also,
  if you are using setuptools, the
  ``install_requires`` keyword works just like
  ``requires`` for metadata purposes. (It
  doesn't in plain setuptools.) 

- Changed ``__requires__`` variable to
  ``__install_requires__`` to ensure
  compatibility with setuptools; if using
  distutils, the keyword is changed to
  ``requires`` before calling the distutils
  ``setup`` function.

- Added support for local archive repositories:
  if the environment variable ``PYPI_LOCAL``
  is set, it is assumed to point to a
  repository directory. The repository directory
  may itself contain archive files, or it may
  contain subdirectories; each subdirectory of
  the root should then have the name of a project
  (i.e., a name that appears in a ``requires``
  list), and in each subdirectory should be
  archives similar to those found on PyPI. If
  a local repository exists and contains a
  version at least equal to the version found
  online, the local archive is used.

- Added automatic generation of license
  classifier from ``__license__`` variable,
  if the latter is one of the values
  corresponding to a classifier. If this
  is done, the __license__ variable is
  removed per the PyPI documentation (which
  says that the license keyword should only
  be used for licenses that don't have a
  Trove classifier).

- Added automatic generation of ``url``
  keyword if not specified; it defaults to
  the PyPI project page for the appropriate
  version of project ``__progname__``.

- Added doctest test file for version_tuple
  and version_string functions.

Version 0.2
-----------

- Added ``__dev_status__`` variable for the
  development status; it automatically adds
  the appropriate classifier.

- The __requires__ variable is only processed
  if the setup command is ``build``, ``clean``,
  or ``install``. If the command is ``clean``,
  the only requirement processing is to run
  the clean command for requirements that are
  already downloaded and unpacked.

- Added support for ``__package_dir__``, the
  standard distutils keyword specifying a
  mapping of package names to subdirectories
  of the setup directory; if the empty string
  '' is a key, its value specifies the 'root'
  of the source tree for both standalone
  modules and packages.

- Changed the meaning of ``__package_root__``
  and ``__package_dirs__``; ``__package_root__`` now
  specifies the root of the source tree,
  equivalent to package_dir[''], and
  ``__package_dirs__`` now specifies subdirs of
  ``__package_root__`` that contain packages
  (if the default auto-detection is not good
  enough).

- Added ``__post_install__`` variable to allow
  running of post-install scripts.

Version 0.1
-----------

Initial version.

TODO Items
----------

- Add Python 3.0 version (to be found on
  PyPI as the ``setuphelper3`` package).
