Removed setuptools support :(

README.rst

@@ -2,188 +2,46 @@
 Buildout
 ********
 
-*Note*: the 1.4.4 release is a release for people who encounter trouble
-with the 1.5 line.  By switching to `the associated bootstrap script
-<https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py>`_
-you can stay on 1.4.4 until you are ready to migrate.
-
-.. contents::
-
-The Buildout project provides support for creating applications,
-especially Python applications.  It provides tools for assembling
-applications from multiple parts, Python or otherwise.  An application
-may actually contain multiple programs, processes, and configuration
-settings.
-
-The word "buildout" refers to a description of a set of parts and the
-software to create and assemble them.  It is often used informally to
-refer to an installed system based on a buildout definition.  For
-example, if we are creating an application named "Foo", then "the Foo
-buildout" is the collection of configuration and application-specific
-software that allows an instance of the application to be created.  We
-may refer to such an instance of the application informally as "a Foo
-buildout".
-
-To get a feel for some of the things you might use buildouts for, see
-the `Buildout examples`_.
-
-To lean more about using buildouts, see `Detailed Documentation`_.
-
-To see screencasts, talks, useful links and more documentation, visit
-the `Buildout website <http://www.buildout.org>`_.
-
-Recipes
-*******
-
-Existing recipes include:
-
-`zc.recipe.egg <http://pypi.python.org/pypi/zc.recipe.egg>`_
-   The egg recipe installes one or more eggs, with their
-   dependencies.  It installs their console-script entry points with
-   the needed eggs included in their paths.
-
-For an extensive list of recipes, look at the `Framework Buildout category
-<http://pypi.python.org/pypi?:action=browse&c=512>`_ on the Python Package
-Index.
-
-Buildout examples
-*****************
-
-Here are a few examples of what you can do with buildouts.  We'll
-present these as a set of use cases.
-
-Try out an egg
-==============
-
-Sometimes you want to try an egg (or eggs) that someone has released.
-You'd like to get a Python interpreter that lets you try things
-interactively or run sample scripts without having to do path
-manipulations.  If you can and don't mind modifying your Python
-installation, you could use easy_install, otherwise, you could create
-a directory somewhere and create a buildout.cfg file in that directory
-containing::
-
-  [buildout]
-  parts = mypython
-
-  [mypython]
-  recipe = zc.recipe.egg
-  interpreter = mypython
-  eggs = theegg
-
-where theegg is the name of the egg you want to try out.
-
-Run buildout in this directory.  It will create a bin subdirectory
-that includes a mypython script.  If you run mypython without any
-arguments you'll get an interactive interpreter with the egg in the
-path. If you run it with a script and script arguments, the script
-will run with the egg in its path.  Of course, you can specify as many
-eggs as you want in the eggs option.
-
-If the egg provides any scripts (console_scripts entry points), those
-will be installed in your bin directory too.
-
-Work on a package
-=================
-
-I often work on packages that are managed separately.  They don't have
-scripts to be installed, but I want to be able to run their tests
-using the `zope.testing test runner
-<http://www.python.org/pypi/zope.testing>`_.  In this kind of
-application, the program to be installed is the test runner.  A good
-example of this is `zc.ngi <http://svn.zope.org/zc.ngi/trunk/>`_.
-
-Here I have a subversion project for the zc.ngi package.  The software
-is in the src directory.  The configuration file is very simple::
-
-  [buildout]
-  develop = .
-  parts = test
-
-  [test]
-  recipe = zc.recipe.testrunner
-  eggs = zc.ngi
-
-I use the develop option to create a develop egg based on the current
-directory.  I request a test script named "test" using the
-zc.recipe.testrunner recipe.  In the section for the test script, I
-specify that I want to run the tests in the zc.ngi package.
-
-When I check out this project into a new sandbox, I run bootstrap.py
-to get setuptools and buildout and to create bin/buildout.  I run
-bin/buildout, which installs the test script, bin/test, which I can
-then use to run the tests.
-
-This is probably the most common type of buildout.
-
-If I need to run a previous version of buildout, I use the
-`--version` option of the bootstrap.py script::
-
-    $ python bootstrap.py --version 1.4.2
-
-The `buildout project <https://github.com/buildout/buildout>`_
-is a slightly more complex example of this type of buildout.
-
-Install egg-based scripts
-=========================
-
-A variation of the `Try out an egg`_ use case is to install scripts
-into your ~/bin directory (on Unix, of course).  My ~/bin directory is
-a buildout with a configuration file that looks like::
-
-
-  [buildout]
-  parts = foo bar
-  bin-directory = .
-
-  [foo]
-  ...
-
-where foo and bar are packages with scripts that I want available.  As
-I need new scripts, I can add additional sections.  The bin-directory
-option specified that scripts should be installed into the current
-directory.
-
-Multi-program multi-machine systems
-===================================
-
-Using an older prototype version of the buildout, we've build a number
-of systems involving multiple programs, databases, and machines.  One
-typical example consists of:
-
-- Multiple Zope instances
-
-- Multiple ZEO servers
-
-- An LDAP server
-
-- Cache-invalidation and Mail delivery servers
-
-- Dozens of add-on packages
-
-- Multiple test runners
-
-- Multiple deployment modes, including dev, stage, and prod,
-  with prod deployment over multiple servers
-
-Parts installed include:
-
-- Application software installs, including Zope, ZEO and LDAP
-  software
-
-- Add-on packages
-
-- Bundles of configuration that define Zope, ZEO and LDAP instances
-
-- Utility scripts such as test runners, server-control
-  scripts, cron jobs.
-
-Questions and Bug Reporting
-***************************
-
-Please send questions and comments to the
-`distutils SIG mailing list <mailto://distutils-sig@python.org>`_.
-
-Report bugs using the `buildout Issues Tracker
-<https://github.com/buildout/buildout/issues>`_.
-
+Buildout is a project designed to solve 2 problems:
+
+1. Application-centric assembly and deployment
+
+   *Assembly* runs the gamut from stitching together libraries to
+   create a running program, to production deployment configuration of
+   applications, and associated systems and tools (e.g. run-control
+   scripts, cron jobs, logs, service registration, etc.).
+
+   Buildout might be confused with build tools like make or ant, but
+   it is a little higher level and might invoke systems like make or
+   ant to get it's work done.
+
+   Buildout might be confused with systems like puppet or chef, but it
+   is more application focused.  Systems like puppet or chef might
+   use buildout to get their work done.
+
+   Buildout is also somewhat Python-centric, even though it can be
+   used to assemble and deploy non-python applications.  It has some
+   special features for assembling Python programs. It's scripted with
+   Python, unlike, say puppet or chef, which are scripted with Ruby.
+
+2. Repeatable assembly of programs from Python software distributions
+
+   Buildout puts great effort toward making program assembly a highly
+   repeatable process, whether in a very open-ended development mode,
+   where dependency versions aren't locked down, or in a deployment
+   environment where dependency versions are fully specified.  You
+   should be able to check buildout into a VCS and later check it out.
+   Two checkouts built at the same time in the same environment should
+   always give the same result, regardless of their history.  Among
+   other things, after a buildout, all dependencies should be at the
+   most recent version consistent with any version specifications
+   expressed in the buildout.
+
+   Buildout supports applications consisting of multiple programs,
+   with different programs in an application free to use different
+   versions of Python distributions.  This is in contrast with a
+   Python installation (real or virtual), where, for any given
+   distribution, there can only be one installed.
+
+To learn more about buildout, including how to use it, see the
+``Buildout Documentation <http://packages.python.org/buildout/>``_.

bootstrap/bootstrap.py

@@ -34,10 +34,6 @@ parser.add_option("-v", "--version", dest="version", default='1.4.4',
                           help='Use a specific zc.buildout version.  *This '
                           'bootstrap script defaults to '
                           '1.4.4, unlike usual buildpout bootstrap scripts.*')
-parser.add_option("-d", "--distribute",
-                   action="store_true", dest="distribute", default=False,
-                   help="Use Disribute rather than Setuptools.")
-
 parser.add_option("-c", None, action="store", dest="config_file",
                    help=("Specify the path to the buildout configuration "
                          "file to be used."))
@@ -53,7 +49,6 @@ if options.version is not None:
 else:
     VERSION = ''
 
-USE_DISTRIBUTE = options.distribute
 args = args + ['bootstrap']
 
 to_reload = False
@@ -64,14 +59,9 @@ try:
         raise ImportError
 except ImportError:
     ez = {}
-    if USE_DISTRIBUTE:
     exec urllib2.urlopen('http://python-distribute.org/distribute_setup.py'
                          ).read() in ez
     ez['use_setuptools'](to_dir=tmpeggs, download_delay=0, no_fake=True)
-    else:
-        exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
-                             ).read() in ez
-        ez['use_setuptools'](to_dir=tmpeggs, download_delay=0)
 
     if to_reload:
         reload(pkg_resources)
@@ -80,10 +70,7 @@ except ImportError:
 
 ws  = pkg_resources.working_set
 
-if USE_DISTRIBUTE:
-    requirement = 'distribute'
-else:
-    requirement = 'setuptools'
+requirement = 'distribute'
 
 env = dict(os.environ,
            PYTHONPATH=
@@ -99,7 +86,6 @@ if 'bootstrap-testing-find-links' in os.environ:
 
 cmd.append('zc.buildout' + VERSION)
 
-
 import subprocess
 if subprocess.call(cmd, env=env) != 0:
     raise Exception(

dev.py

@@ -34,7 +34,8 @@ try:
     import pkg_resources
 except ImportError:
     ez = {}
-    exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py'
+    exec urllib2.urlopen(
+        'http://python-distribute.org/distribute_setup.py'
         ).read() in ez
     ez['use_setuptools'](to_dir='eggs', download_delay=0)
 

src/zc/buildout/bootstrap.txt

@@ -57,6 +57,7 @@ Let's try with an unknown version::
     ...     'bootstrap.py --version UNKNOWN'); print 'X' # doctest: +ELLIPSIS
     ...
     X
+    ...
     No local packages or download links found for zc.buildout==UNKNOWN
     ...
 
@@ -65,8 +66,9 @@ Now let's try with `1.1.2`, which happens to exist::
     >>> print 'X'; print system(
     ...     zc.buildout.easy_install._safe_arg(sys.executable)+' '+
     ...     'bootstrap.py --version 1.1.2'); print 'X'
-    ...
+    ... # doctest: +ELLIPSIS
     X
+    ...
     Generated script '/sample/bin/buildout'.
     <BLANKLINE>
     X
@@ -81,7 +83,7 @@ Let's make sure the generated `buildout` script uses it::
     <BLANKLINE>
     import sys
     sys.path[0:0] = [
-      '/sample/eggs/setuptools-...egg',
+      '/sample/eggs/distribute-...egg',
       '/sample/eggs/zc.buildout-1.1.2...egg',
       ]
     <BLANKLINE>
@@ -98,35 +100,6 @@ Let's try with `1.2.1`::
     ...     'bootstrap.py --version 1.2.1'); print 'X' # doctest: +ELLIPSIS
     ...
     X
-    Generated script '/sample/bin/buildout'.
-    <BLANKLINE>
-    X
-
-Let's make sure the generated `buildout` script uses it::
-
-    >>> print open(buildout_script).read() # doctest: +ELLIPSIS
-    #...
-    <BLANKLINE>
-    import sys
-    sys.path[0:0] = [
-      '/sample/eggs/setuptools-...egg',
-      '/sample/eggs/zc.buildout-1.2.1...egg',
-      ]
-    <BLANKLINE>
-    import zc.buildout.buildout
-    <BLANKLINE>
-    if __name__ == '__main__':
-        zc.buildout.buildout.main()
-    <BLANKLINE>
-
-`zc.buildout` now can also run with `Distribute` with the `--distribute` option::
-
-
-    >>> print 'X'; print system(
-    ...     zc.buildout.easy_install._safe_arg(sys.executable)+' '+
-    ...     'bootstrap.py --distribute'); print 'X' # doctest: +ELLIPSIS
-    ...
-    X
     ...
     Generated script '/sample/bin/buildout'.
     <BLANKLINE>
@@ -134,35 +107,6 @@ Let's make sure the generated `buildout` script uses it::
 
 Let's make sure the generated `buildout` script uses it::
 
-    >>> print open(buildout_script).read() # doctest: +ELLIPSIS
-    #...
-    <BLANKLINE>
-    import sys
-    sys.path[0:0] = [
-      '/sample/eggs/distribute-...egg',
-      '/sample/eggs/zc.buildout-...egg',
-      ]
-    <BLANKLINE>
-    import zc.buildout.buildout
-    <BLANKLINE>
-    if __name__ == '__main__':
-        zc.buildout.buildout.main()
-    <BLANKLINE>
-
-Make sure both options can be used together::
-
-    >>> print 'X'; print system(
-    ...     zc.buildout.easy_install._safe_arg(sys.executable)+' '+
-    ...     'bootstrap.py --distribute --version 1.2.1'); print 'X' # doctest: +ELLIPSIS
-    ...
-    X
-    ...
-    Generated script '/sample/bin/buildout'.
-    <BLANKLINE>
-    X
-
-Let's make sure the generated `buildout` script uses ``Distribute`` *and* ``zc.buildout-1.2.1``::
-
     >>> print open(buildout_script).read() # doctest: +ELLIPSIS
     #...
     <BLANKLINE>
@@ -178,20 +122,4 @@ Let's make sure the generated `buildout` script uses ``Distribute`` *and* ``zc.b
         zc.buildout.buildout.main()
     <BLANKLINE>
 
-Last, the -c option needs to work on bootstrap.py::
-
-    >>> conf_file = os.path.join(sample_buildout, 'other.cfg')
-    >>> f = open(conf_file, 'w')
-    >>> f.write('[buildout]\nparts=\n\n')
-    >>> f.close()
-    >>> print 'X'; print system(
-    ...     zc.buildout.easy_install._safe_arg(sys.executable)+' '+
-    ...     'bootstrap.py -c %s --distribute' % conf_file); print 'X' # doctest: +ELLIPSIS
-    ...
-    X
-    ...
-    Generated script '/sample/bin/buildout'.
-    <BLANKLINE>
-    X
-
 

src/zc/buildout/buildout.py

@@ -43,7 +43,7 @@ import zc.buildout.easy_install
 realpath = zc.buildout.easy_install.realpath
 
 pkg_resources_loc = pkg_resources.working_set.find(
-    pkg_resources.Requirement.parse('setuptools')).location
+    pkg_resources.Requirement.parse('distribute')).location
 
 _isurl = re.compile('([a-zA-Z0-9+.-]+)://').match
 
@@ -355,9 +355,9 @@ class Buildout(UserDict.DictMixin):
 
         self._setup_directories()
 
-        # Now copy buildout and setuptools eggs, and record destination eggs:
+        # Now copy buildout and distribute eggs, and record destination eggs:
         entries = []
-        for name in 'setuptools', 'zc.buildout':
+        for name in 'distribute', 'zc.buildout':
             r = pkg_resources.Requirement.parse(name)
             dist = pkg_resources.working_set.find(r)
             if dist.precedence == pkg_resources.DEVELOP_DIST:
@@ -802,7 +802,7 @@ class Buildout(UserDict.DictMixin):
         self._log_level = level
 
     def _maybe_upgrade(self):
-        # See if buildout or setuptools need to be upgraded.
+        # See if buildout or distribute need to be upgraded.
         # If they do, do the upgrade and restart the buildout process.
         __doing__ = 'Checking for upgrades.'
 
@@ -812,7 +812,7 @@ class Buildout(UserDict.DictMixin):
         ws = zc.buildout.easy_install.install(
             [
             (spec + ' ' + self['buildout'].get(spec+'-version', '')).strip()
-            for spec in ('zc.buildout', 'setuptools')
+            for spec in ('zc.buildout', 'distribute')
             ],
             self['buildout']['eggs-directory'],
             links = self['buildout'].get('find-links', '').split(),
@@ -822,7 +822,7 @@ class Buildout(UserDict.DictMixin):
             )
 
         upgraded = []
-        for project in 'zc.buildout', 'setuptools':
+        for project in 'zc.buildout', 'distribute':
             req = pkg_resources.Requirement.parse(project)
             project_location = pkg_resources.working_set.find(req).location
             if ws.find(req).location != project_location:
@@ -930,7 +930,7 @@ class Buildout(UserDict.DictMixin):
         fd, tsetup = tempfile.mkstemp()
         try:
             os.write(fd, zc.buildout.easy_install.runsetup_template % dict(
-                setuptools=pkg_resources_loc,
+                distribute=pkg_resources_loc,
                 setupdir=os.path.dirname(setup),
                 setup=setup,
                 __file__ = setup,
@@ -1537,7 +1537,7 @@ Commands:
   bootstrap
 
     Create a new buildout in the current working directory, copying
-    the buildout and setuptools eggs and, creating a basic directory
+    the buildout and distribute eggs and, creating a basic directory
     structure and a buildout-local buildout script.
 
   init
@@ -1548,10 +1548,10 @@ Commands:
 
   setup script [setup command and options]
 
-    Run a given setup script arranging that setuptools is in the
+    Run a given setup script arranging that distribute is in the
     script's path and and that it has been imported so that
-    setuptools-provided commands (like bdist_egg) can be used even if
-    the setup script doesn't import setuptools itself.
+    distribute-provided commands (like bdist_egg) can be used even if
+    the setup script doesn't import setuptools.
 
     The script can be given either as a script path or a path to a
     directory containing a setup.py script.

src/zc/buildout/buildout.txt

@@ -18,7 +18,7 @@ buildout software and create a buildout instance:
    script installed in a Python scripts area.
 
 2. Use the buildout bootstrap script to create a buildout that
-   includes both the setuptools and zc.buildout eggs.  This allows you
+   includes both the distribute and zc.buildout eggs.  This allows you
    to use the buildout software without modifying a Python install.
    The buildout script is installed into your buildout local scripts
    area.
@@ -32,7 +32,7 @@ such as a subversion repository, that includes some software source
 directories, buildout configuration files, and a copy of the buildout
 bootstrap script.  To work on the project, one would check out the
 project from the repository and run the bootstrap script which
-installs setuptools and zc.buildout into the checkout as well as any
+installs distribute and zc.buildout into the checkout as well as any
 parts defined.
 
 We have a sample buildout that we created using the bootstrap command
@@ -53,7 +53,7 @@ The bin directory contains scripts.
     -  buildout
 
     >>> ls(sample_buildout, 'eggs')
-    -  setuptools-0.6-py2.4.egg
+    -  distribute-0.6-py2.4.egg
     -  zc.buildout-1.0-py2.4.egg
 
 The develop-eggs and parts directories are initially empty:
@@ -228,7 +228,7 @@ classes must be exposed as entry points in the zc.buildout group.  we
 give entry points names within the group.
 
 We also need a README.txt for our recipes to avoid an annoying warning
-from distutils, on which setuptools and zc.buildout are based:
+from distutils, on which distribute and zc.buildout are based:
 
     >>> write(sample_buildout, 'recipes', 'README.txt', " ")
 
@@ -2194,10 +2194,10 @@ database is shown.
     ... """)
 
     >>> print system(buildout+' -vv'), # doctest: +NORMALIZE_WHITESPACE
-    Installing 'zc.buildout', 'setuptools'.
+    Installing 'zc.buildout', 'distribute'.
     We have a develop egg: zc.buildout 1.0.0.
-    We have the best distribution that satisfies 'setuptools'.
-    Picked: setuptools = 0.6
+    We have the best distribution that satisfies 'distribute'.
+    Picked: distribute = 0.6
     <BLANKLINE>
     Configuration data:
     [buildout]
@@ -2267,7 +2267,7 @@ Creating new buildouts and bootstrapping
 ----------------------------------------
 
 If zc.buildout is installed, you can use it to create a new buildout
-with it's own local copies of zc.buildout and setuptools and with
+with it's own local copies of zc.buildout and distribute and with
 local buildout scripts.
 
     >>> sample_bootstrapped = tmpdir('sample-bootstrapped')
@@ -2296,13 +2296,13 @@ Note that a basic setup.cfg was created for us.
 
     >>> _ = (ls(sample_bootstrapped, 'eggs'),
     ...      ls(sample_bootstrapped, 'develop-eggs'))
-    -  setuptools-0.6-py2.3.egg
+    -  distribute-0.6-py2.3.egg
     -  zc.buildout-1.0-py2.3.egg
 
 (We list both the eggs and develop-eggs directories because the
-buildout or setuptools egg could be installed in the develop-eggs
+buildout or distribute egg could be installed in the develop-eggs
 directory if the original buildout had develop eggs for either
-buildout or setuptools.)
+buildout or distribute.)
 
 Note that the buildout script was installed but not run.  To run
 the buildout, we'd have to run the installed buildout script.

src/zc/buildout/easy_install.py

@@ -14,7 +14,7 @@
 """Python easy_install API
 
 This module provides a high-level Python API for installing packages.
-It doesn't install scripts.  It uses setuptools and requires it to be
+It doesn't install scripts.  It uses distribute and requires it to be
 installed.
 """
 
@@ -56,13 +56,13 @@ if is_jython:
     jython_os_name = (java.lang.System.getProperties()['os.name']).lower()
 
 
-setuptools_loc = pkg_resources.working_set.find(
-    pkg_resources.Requirement.parse('setuptools')
+distribute_loc = pkg_resources.working_set.find(
+    pkg_resources.Requirement.parse('distribute')
     ).location
 
-# Include buildout and setuptools eggs in paths
-buildout_and_setuptools_path = [
-    setuptools_loc,
+# Include buildout and distribute eggs in paths
+buildout_and_distribute_path = [
+    distribute_loc,
     pkg_resources.working_set.find(
         pkg_resources.Requirement.parse('zc.buildout')).location,
     ]
@@ -162,7 +162,7 @@ class Installer:
         self._index_url = index
         if always_unzip is not None:
             self._always_unzip = always_unzip
-        path = (path and path[:] or []) + buildout_and_setuptools_path
+        path = (path and path[:] or []) + buildout_and_distribute_path
         if dest is not None and dest not in path:
             path.insert(0, dest)
         self._path = path
@@ -273,7 +273,7 @@ class Installer:
 
         tmp = tempfile.mkdtemp(dir=dest)
         try:
-            path = setuptools_loc
+            path = distribute_loc
 
             args = [sys.executable, '-c', _easy_install_cmd, '-mUNxd', tmp]
             if self._always_unzip:
@@ -417,7 +417,7 @@ class Installer:
             and (realpath(new_location) == realpath(dist.location))
             and os.path.isfile(new_location)
             ):
-            # setuptools avoids making extra copies, but we want to copy
+            # distribute avoids making extra copies, but we want to copy
             # to the download cache
             shutil.copy2(new_location, tmp)
             new_location = os.path.join(tmp, os.path.basename(new_location))
@@ -542,21 +542,21 @@ class Installer:
 
         return dists
 
-    def _maybe_add_setuptools(self, ws, dist):
+    def _maybe_add_distribute(self, ws, dist):
         if dist.has_metadata('namespace_packages.txt'):
             for r in dist.requires():
-                if r.project_name == 'setuptools':
+                if r.project_name in ('setuptools', 'distribute'):
                     break
             else:
-                # We have a namespace package but no requirement for setuptools
+                # We have a namespace package but no requirement for distribute
                 if dist.precedence == pkg_resources.DEVELOP_DIST:
                     logger.warn(
                         "Develop distribution: %s\n"
                         "uses namespace packages but the distribution "
-                        "does not require setuptools.",
+                        "does not require distribute.",
                         dist)
                 requirement = self._constrain(
-                    pkg_resources.Requirement.parse('setuptools')
+                    pkg_resources.Requirement.parse('distribute')
                     )
                 if ws.find(requirement) is None:
                     for dist in self._get_dist(requirement, ws, False):
@@ -600,7 +600,7 @@ class Installer:
         for requirement in requirements:
             for dist in self._get_dist(requirement, ws, self._always_unzip):
                 ws.add(dist)
-                self._maybe_add_setuptools(ws, dist)
+                self._maybe_add_distribute(ws, dist)
 
         # OK, we have the requested distributions and they're in the working
         # set, but they may have unmet requirements.  We'll simply keep
@@ -626,7 +626,7 @@ class Installer:
                                            ):
 
                     ws.add(dist)
-                    self._maybe_add_setuptools(ws, dist)
+                    self._maybe_add_distribute(ws, dist)
             except pkg_resources.VersionConflict, err:
                 raise VersionConflict(err, ws)
             else:
@@ -823,7 +823,7 @@ def develop(setup, dest,
         undo.append(lambda: os.close(fd))
 
         os.write(fd, runsetup_template % dict(
-            setuptools=setuptools_loc,
+            distribute=distribute_loc,
             setupdir=directory,
             setup=setup,
             __file__ = setup,
@@ -1006,7 +1006,7 @@ def _script(module_name, attrs, path, dest, arguments, initialization, rsetup):
     if is_win32:
         # generate exe file and give the script a magic name:
         exe = script+'.exe'
-        new_data = pkg_resources.resource_string('setuptools', 'cli.exe')
+        new_data = pkg_resources.resource_string('distribute', 'cli.exe')
         if not os.path.exists(exe) or (open(exe, 'rb').read() != new_data):
             # Only write it if it's different.
             open(exe, 'wb').write(new_data)
@@ -1062,7 +1062,7 @@ def _pyscript(path, dest, rsetup):
         # generate exe file and give the script a magic name:
         exe = script + '.exe'
         open(exe, 'wb').write(
-            pkg_resources.resource_string('setuptools', 'cli.exe')
+            pkg_resources.resource_string('distribute', 'cli.exe')
             )
         generated.append(exe)
 
@@ -1115,7 +1115,7 @@ if _interactive:
 runsetup_template = """
 import sys
 sys.path.insert(0, %(setupdir)r)
-sys.path.insert(0, %(setuptools)r)
+sys.path.insert(0, %(distribute)r)
 import os, setuptools
 
 __file__ = %(__file__)r

src/zc/buildout/easy_install.txt

@@ -136,7 +136,7 @@ And the actual eggs were added to the eggs directory.
 
     >>> ls(dest)
     -  demo-0.2-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
 
 If we remove the version restriction on demo, but specify a false
 value for newest, no new distributions will be installed:
@@ -146,7 +146,7 @@ value for newest, no new distributions will be installed:
     ...     newest=False)
     >>> ls(dest)
     -  demo-0.2-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
 
 If we leave off the newest option, we'll get an update for demo:
 
@@ -155,7 +155,7 @@ If we leave off the newest option, we'll get an update for demo:
     >>> ls(dest)
     -  demo-0.2-py2.4.egg
     -  demo-0.3-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
 
 Note that we didn't get the newest versions available.  There were
 release candidates for newer versions of both packages. By default,
@@ -178,8 +178,8 @@ The old setting is returned.
     -  demo-0.2-py2.4.egg
     -  demo-0.3-py2.4.egg
     -  demo-0.4c1-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
-    -  demoneeded-1.2c1-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.2c1-py2.4.egg
 
 Let's put the setting back to the default.
 
@@ -204,9 +204,9 @@ dependencies.  We might do this to specify a specific version.
     -  demo-0.2-py2.4.egg
     -  demo-0.3-py2.4.egg
     -  demo-0.4c1-py2.4.egg
-    -  demoneeded-1.0-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
-    -  demoneeded-1.2c1-py2.4.egg
+    d  demoneeded-1.0-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.2c1-py2.4.egg
     d  other-1.0-py2.4.egg
 
 We can request that eggs be unzipped even if they are zip safe.  This
@@ -230,7 +230,7 @@ can be useful when debugging.
 
     >>> ls(dest)
     -  demo-0.3-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
 
 We can also set a default by calling the always_unzip function:
 
@@ -259,7 +259,7 @@ The old default is returned:
 
     >>> ls(dest)
     -  demo-0.3-py2.4.egg
-    -  demoneeded-1.1-py2.4.egg
+    d  demoneeded-1.1-py2.4.egg
 
     >>> rmdir(dest)
     >>> dest = tmpdir('sample-install')
@@ -1009,7 +1009,7 @@ Now if we look in our destination directory, we see we have an extdemo egg:
     >>> ls(dest)
     -  demo-0.2-py2.4.egg
     d  demo-0.3-py2.4.egg
-    -  demoneeded-1.0-py2.4.egg
+    d  demoneeded-1.0-py2.4.egg
     d  demoneeded-1.1-py2.4.egg
     d  extdemo-1.4-py2.4-unix-i686.egg
 
@@ -1050,7 +1050,7 @@ If we run build with newest set to False, we won't get an update:
     >>> ls(dest)
     -  demo-0.2-py2.4.egg
     d  demo-0.3-py2.4.egg
-    -  demoneeded-1.0-py2.4.egg
+    d  demoneeded-1.0-py2.4.egg
     d  demoneeded-1.1-py2.4.egg
     d  extdemo-1.4-py2.4-unix-i686.egg
 
@@ -1066,7 +1066,7 @@ get an updated egg:
     >>> ls(dest)
     -  demo-0.2-py2.4.egg
     d  demo-0.3-py2.4.egg
-    -  demoneeded-1.0-py2.4.egg
+    d  demoneeded-1.0-py2.4.egg
     d  demoneeded-1.1-py2.4.egg
     d  extdemo-1.4-py2.4-unix-i686.egg
     d  extdemo-1.5-py2.4-unix-i686.egg

src/zc/buildout/repeatable.txt

@@ -124,10 +124,10 @@ about versions used. If we run the buildout in verbose mode without
 specifying a versions section:
 
     >>> print system(buildout+' buildout:versions= -v'), # doctest: +ELLIPSIS
-    Installing 'zc.buildout', 'setuptools'.
+    Installing 'zc.buildout', 'distribute'.
     We have a develop egg: zc.buildout 1.0.0.
-    We have the best distribution that satisfies 'setuptools'.
-    Picked: setuptools = 0.6
+    We have the best distribution that satisfies 'distribute'.
+    Picked: distribute = 0.6
     Installing 'spam'.
     We have the best distribution that satisfies 'spam'.
     Picked: spam = 2.
@@ -146,10 +146,10 @@ that we can fix them in a versions section.
 If we run the buildout with the versions section:
 
     >>> print system(buildout+' -v'), # doctest: +ELLIPSIS
-    Installing 'zc.buildout', 'setuptools'.
+    Installing 'zc.buildout', 'distribute'.
     We have a develop egg: zc.buildout 1.0.0.
-    We have the best distribution that satisfies 'setuptools'.
-    Picked: setuptools = 0.6
+    We have the best distribution that satisfies 'distribute'.
+    Picked: distribute = 0.6
     Installing 'spam'.
     We have the distribution that satisfies 'spam==1'.
     Uninstalling foo.
@@ -157,7 +157,7 @@ If we run the buildout with the versions section:
     recipe v1
 
 We won't get output for the spam distribution, which we didn't pick,
-but we will get output for setuptools, which we didn't specify
+but we will get output for distribute, which we didn't specify
 versions for.
 
 You can request buildout to generate an error if it picks any

src/zc/buildout/runsetup.txt

@@ -5,12 +5,12 @@ Buildouts are often used to work on packages that will be distributed
 as eggs. During development, we use develop eggs.  When you've
 completed a development cycle, you'll need to run your setup script to
 generate a distribution and, perhaps, uploaded it to the Python
-package index.  If your script uses setuptools, you'll need setuptools
+package index.  If your script uses setuptools, you'll need distribute
 in your Python path, which may be an issue if you haven't installed
-setuptools into your Python installation.
+distribute into your Python installation.
 
 The buildout setup command is helpful in a situation like this.  It
-can be used to run a setup script and it does so with the setuptools
+can be used to run a setup script and it does so with the distribute
 egg in the Python path and with setuptools already imported.  The fact
 that setuptools is imported means that you can use setuptools-based
 commands, like bdist_egg even with packages that don't use setuptools.

src/zc/buildout/setup.txt

@@ -10,7 +10,7 @@ running the script so setuptools-provided commands are available.
 If you use a squeaky-clean Python to do your development, the setup
 script that would import setuptools because setuptools isn't in the
 path.  Because buildout requires setuptools and knows where it has
-installed a setuptools egg, it adds the setuptools egg to the Python
+installed a distribute egg, it adds the distribute egg to the Python
 path before running the script.  To run a setup script, use the
 buildout setup command, passing the name of a script or a directory
 containing a setup script and arguments to the script.  Let's look at

src/zc/buildout/testing.py

@@ -39,8 +39,8 @@ from zc.buildout.rmtree import rmtree
 fsync = getattr(os, 'fsync', lambda fileno: None)
 is_win32 = sys.platform == 'win32'
 
-setuptools_location = pkg_resources.working_set.find(
-    pkg_resources.Requirement.parse('setuptools')).location
+distribute_location = pkg_resources.working_set.find(
+    pkg_resources.Requirement.parse('distribute')).location
 
 def cat(dir, *names):
     path = os.path.join(dir, *names)
@@ -118,7 +118,7 @@ def _runsetup(setup, *args):
         os.chdir(os.path.dirname(setup))
         zc.buildout.easy_install.call_subprocess(
             [sys.executable, setup] + args,
-            env=dict(os.environ, PYTHONPATH=setuptools_location))
+            env=dict(os.environ, PYTHONPATH=distribute_location))
         if os.path.exists('build'):
             rmtree('build')
     finally:

src/zc/buildout/unzip.txt

@@ -17,8 +17,8 @@ By default, zc.buildout doesn't unzip zip-safe eggs.
     >>> _ = system(buildout)
     >>> ls('eggs')
     -  demo-0.4c1-py2.4.egg
-    -  demoneeded-1.2c1-py2.4.egg
-    d  setuptools-0.6c8-py2.4.egg
+    d  demoneeded-1.2c1-py2.4.egg
+    d  distribute-0.6c8-py2.4.egg
     -  zc.buildout.egg-link
 
 This follows the policy followed by setuptools itself.  Experience shows
@@ -50,5 +50,5 @@ default unzipping policy.
     >>> ls('eggs')
     d  demo-0.4c1-py2.4.egg
     d  demoneeded-1.2c1-py2.4.egg
-    d  setuptools-0.6c8-py2.4.egg
+    d  distribute-0.6c8-py2.4.egg
     -  zc.buildout.egg-link

src/zc/buildout/update.txt

 Automatic Buildout Updates
 ==========================
 
-NOTE: buildout 1.4.4 is a version that has been hacked to prefer itself, and
-not upgrade.  It is intended as a way for people who have trouble with the new
-1.5 line to easily keep from upgrading until they are ready.  In the future,
-we suggest that you specify the versions of your dependencies using the
-standard buildout mechanism
-(http://pypi.python.org/pypi/zc.buildout#repeatable-buildouts-controlling-eggs-used).
-However, for now, you can use 1.4.4 to easily control your dependencies.
-When this file changes because of the hack, the documentation indicates this
-with a "HACK" label.
-
 When a buildout is run, one of the first steps performed is to check for
-updates to either zc.buildout or setuptools (HACK: not zc.buildout).  To
+updates to either zc.buildout or distribute.  To
 demonstrate this, we've created some "new releases" of buildout and
-setuptools in a new_releases folder:
+distribute in a new_releases folder:
 
     >>> ls(new_releases)
-    d  setuptools
-    -  setuptools-99.99-py2.4.egg
+    d  distribute
+    -  distribute-99.99-py2.4.egg
     d  zc.buildout
     -  zc.buildout-99.99-py2.4.egg
 
@@ -36,7 +26,7 @@ Let's update the sample buildout.cfg to look in this area:
     ... recipe = showversions
     ... """ % dict(new_releases=new_releases))
 
-We'll also include a recipe that echos the versions of setuptools and
+We'll also include a recipe that echos the versions of distribute and
 zc.buildout used:
 
     >>> mkdir(sample_buildout, 'showversions')
@@ -51,7 +41,7 @@ zc.buildout used:
     ...         pass
     ...
     ...     def install(self):
-    ...         for project in 'zc.buildout', 'setuptools':
+    ...         for project in 'zc.buildout', 'distribute':
     ...             req = pkg_resources.Requirement.parse(project)
     ...             print project, pkg_resources.working_set.find(req).version
     ...         return ()
@@ -71,22 +61,21 @@ zc.buildout used:
 
 
 Now if we run the buildout, the buildout will upgrade itself to the
-new versions found in new releases (HACK: only setuptools):
+new versions found in new releases:
 
     >>> print system(buildout),
-    Getting distribution for 'setuptools'.
-    Got setuptools 99.99.
+    Getting distribution for 'distribute'.
+    Got distribute 99.99.
     Upgraded:
-      setuptools version 99.99;
+      distribute version 99.99;
     restarting.
     Generated script '/sample-buildout/bin/buildout'.
     Develop: '/sample-buildout/showversions'
     Installing show-versions.
     zc.buildout 1.4.4
-    setuptools 99.99
+    distribute 99.99
 
-Our buildout script has been updated to use the new eggs (HACK: only for
-setuptools):
+Our buildout script has been updated to use the new eggs:
 
     >>> cat(sample_buildout, 'bin', 'buildout')
     #!/usr/local/bin/python2.7
@@ -94,7 +83,7 @@ setuptools):
     import sys
     sys.path[0:0] = [
       '/sample-buildout/eggs/zc.buildout-1.4.4-py2.4.egg',
-      '/sample-buildout/eggs/setuptools-99.99-py2.4.egg',
+      '/sample-buildout/eggs/distribute-99.99-py2.4.egg',
       ]
     <BLANKLINE>
     import zc.buildout.buildout
@@ -103,8 +92,8 @@ setuptools):
         zc.buildout.buildout.main()
 
 Now, let's recreate the sample buildout. If we specify constraints on
-the versions of zc.buildout and setuptools to use, running the buildout
-will install earlier versions of these packages (HACK: only setuptools):
+the versions of zc.buildout and distribute to use, running the buildout
+will install earlier versions of these packages:
 
     >>> write(sample_buildout, 'buildout.cfg',
     ... """
@@ -114,7 +103,7 @@ will install earlier versions of these packages (HACK: only setuptools):
     ... parts = show-versions
     ... develop = showversions
     ... zc.buildout-version = < 99
-    ... setuptools-version = < 99
+    ... distribute-version = < 99
     ...
     ... [show-versions]
     ... recipe = showversions
@@ -124,13 +113,13 @@ Now we can see that we actually "upgrade" to an earlier version.
 
     >>> print system(buildout),
     Upgraded:
-      setuptools version 0.6;
+      distribute version 0.6;
     restarting.
     Generated script '/sample-buildout/bin/buildout'.
     Develop: '/sample-buildout/showversions'
     Updating show-versions.
     zc.buildout 1.0.0
-    setuptools 0.6
+    distribute 0.6
 
 There are a number of cases, described below, in which the updates
 don't happen.
@@ -153,7 +142,7 @@ We won't upgrade in offline mode:
     Develop: '/sample-buildout/showversions'
     Updating show-versions.
     zc.buildout 1.0.0
-    setuptools 0.6
+    distribute 0.6
 
 Or in non-newest mode:
 
@@ -161,7 +150,7 @@ Or in non-newest mode:
     Develop: '/sample-buildout/showversions'
     Updating show-versions.
     zc.buildout 1.0.0
-    setuptools 0.6
+    distribute 0.6
 
 We also won't upgrade if the buildout script being run isn't in the
 buildouts bin directory.  To see this we'll create a new buildout
@@ -182,8 +171,8 @@ directory:
     Creating directory '/sample_buildout2/parts'.
     Creating directory '/sample_buildout2/eggs'.
     Creating directory '/sample_buildout2/develop-eggs'.
-    Getting distribution for 'setuptools'.
-    Got setuptools 99.99.
+    Getting distribution for 'distribute'.
+    Got distribute 99.99.
     Not upgrading because not running a local buildout command.
 
     >>> ls('bin')

src/zc/buildout/upgrading_distribute.txt

-Installing setuptools/distribute
---------------------------------
+Installing distribute
+---------------------
 
 Some initial test setup:
 
@@ -7,15 +7,15 @@ Some initial test setup:
     >>> import zc.buildout
     >>> dest = tmpdir('sample-install')
 
-Setuptools (0.6something) is packaged as an ``.egg``.  So when installing it,
-the egg is downloaded and used.  Distribute is packaged as a tarball, which
-makes an easy_install call necessary.  In older versions of buildout, the
-``_call_easy_install()`` method would call ``_get_dist()`` to get hold of the
-setuptools path for calling easy_install.  When an updated "distribute" was
-found, this would try an install again, leading to an infinite recursion.
+Distribute is packaged as a tarball, which makes an easy_install call
+necessary.  In older versions of buildout, the
+``_call_easy_install()`` method would call ``_get_dist()`` to get hold
+of the setuptools path for calling easy_install.  When an updated
+"distribute" was found, this would try an install again, leading to an
+infinite recursion.
 
-The solution is to just use the setuptools location found at import time, like
-happens with the buildout and setuptools location that is inserted in scripts'
+The solution is to just use the distribute location found at import time, like
+happens with the buildout and distribute location that is inserted in scripts'
 paths.
 
 We test this corner case by patching the ``_get_dist()`` call:
@@ -23,7 +23,7 @@ We test this corner case by patching the ``_get_dist()`` call:
     >>> def mock_get_dist(requirement, ws, always_unzip):
     ...     raise RuntimeError("We should not get called")
 
-When installing setuptools itself, we expect the "Getting dist" message not to
+When installing distribute itself, we expect the "Getting dist" message not to
 be printed.  We call ``_call_easy_install()`` directly and get an error
 because of a non-existing tarball, but that's the OK for this corner case
 test: we only want to test that ``_get_dist()`` isn't getting called:
@@ -34,7 +34,7 @@ test: we only want to test that ``_get_dist()`` isn't getting called:
     ...     @property
     ...     def project_name(self):
     ...         # Testing corner case: there *is* actually
-    ...         # a newer setuptools package on pypi than we
+    ...         # a newer distribute package on pypi than we
     ...         # are running with, so it really installs it
     ...         # and compares project_name. We're past the
     ...         # point that we're testing, so we just raise
@@ -49,7 +49,7 @@ test: we only want to test that ``_get_dist()`` isn't getting called:
     ...     index=link_server+'index/',
     ...     always_unzip=True)
     >>> installer._get_dist = mock_get_dist
-    >>> installer._call_easy_install('setuptools', None, dest, dist)
+    >>> installer._call_easy_install('distribute', None, dest, dist)
     Traceback (most recent call last):
     ...
     UserError: Couldn't install: nonexisting.tgz

zc.recipe.egg_/src/zc/recipe/egg/README.txt

@@ -72,8 +72,8 @@ Now, if we look at the buildout eggs directory:
 
     >>> ls(sample_buildout, 'eggs')
     -  demo-0.2-py2.3.egg
-    -  demoneeded-1.2c1-py2.3.egg
-    -  setuptools-0.6-py2.3.egg
+    d  demoneeded-1.2c1-py2.3.egg
+    -  distribute-0.6-py2.3.egg
     -  zc.buildout-1.0-py2.3.egg
 
 We see that we got an egg for demo that met the requirement, as well
@@ -261,8 +261,8 @@ We didn't get an update for demo:
 
     >>> ls(sample_buildout, 'eggs')
     -  demo-0.2-py2.3.egg
-    -  demoneeded-1.2c1-py2.3.egg
-    -  setuptools-0.6-py2.3.egg
+    d  demoneeded-1.2c1-py2.3.egg
+    -  distribute-0.6-py2.3.egg
     -  zc.buildout-1.0-py2.3.egg
 
 If we run the buildout on the default online and newest modes,
@@ -279,8 +279,8 @@ Then we'll get a new demo egg:
     >>> ls(sample_buildout, 'eggs')
     -  demo-0.2-py2.3.egg
     -  demo-0.4c1-py2.3.egg
-    -  demoneeded-1.2c1-py2.3.egg
-    -  setuptools-0.6-py2.4.egg
+    d  demoneeded-1.2c1-py2.3.egg
+    -  distribute-0.6-py2.4.egg
     -  zc.buildout-1.0-py2.4.egg
 
 The script is updated too:

zc.recipe.egg_/src/zc/recipe/egg/api.txt

@@ -103,7 +103,7 @@ computed by the egg recipe by looking at .installed.cfg:
     __buildout_installed__ = 
     __buildout_signature__ = sample-6aWMvV2EJ9Ijq+bR8ugArQ==
             zc.recipe.egg-cAsnudgkduAa/Fd+WJIM6Q==
-            setuptools-0.6-py2.4.egg
+            distribute-0.6-py2.4.egg
             zc.buildout-+rYeCcmFuD1K/aB77XTj5A==
     _b = /sample-buildout/bin
     _d = /sample-buildout/develop-eggs

zc.recipe.egg_/src/zc/recipe/egg/egg.py

@@ -152,11 +152,11 @@ class Scripts(Eggs):
 
             if get_bool(options, 'dependent-scripts'):
                 # Generate scripts for all packages in the working set,
-                # except setuptools.
+                # except distribute.
                 reqs = list(reqs)
                 for dist in ws:
                     name = dist.project_name
-                    if name != 'setuptools' and name not in reqs:
+                    if name != 'distribute' and name not in reqs:
                         reqs.append(name)
 
             return zc.buildout.easy_install.scripts(

zc.recipe.egg_/src/zc/recipe/egg/tests.py

@@ -45,7 +45,7 @@ def test_suite():
                zc.buildout.tests.normalize_bang,
                (re.compile('zc.buildout(-\S+)?[.]egg(-link)?'),
                 'zc.buildout.egg'),
-               (re.compile('[-d]  setuptools-[^-]+-'), 'setuptools-X-'),
+               (re.compile('[-d]  distribute-[^-]+-'), 'distribute-X-'),
                (re.compile(r'eggs\\\\demo'), 'eggs/demo'),
                (re.compile(r'[a-zA-Z]:\\\\foo\\\\bar'), '/foo/bar'),
                ])
@@ -59,7 +59,7 @@ def test_suite():
                (re.compile('__buildout_signature__ = '
                            'sample-\S+\s+'
                            'zc.recipe.egg-\S+\s+'
-                           'setuptools-\S+\s+'
+                           'distribute-\S+\s+'
                            'zc.buildout-\S+\s*'
                            ),
                 '__buildout_signature__ = sample- zc.recipe.egg-'),