updates based on discussion on distutils-sig:

- add handling of setuptools requirements in package installation
- add ref to the pip issue tracking PEP implementation
- re-work the structure of the PEP to make it clearer (hopefully)

pep-0439.txt

@@ -54,7 +54,15 @@ beyond requiring Python installation upgrades.
 Proposal
 ========
 
-Python install includes an executable called "pip" that attempts to
+This proposal affects three components of packaging: `the pip bootstrap`_,
+`setuptools`_ and, thanks to easier package installation, `modifications to
+publishing packages`_.
+
+
+The pip bootstrap
+-----------------
+
+The Python installation includes an executable called "pip" that attempts to
 import pip machinery.  If it can then the pip command proceeds as
 normal.  If it cannot it will bootstrap pip by downloading the pip
 implementation wheel file.  Once installed, the pip command proceeds
@@ -72,7 +80,7 @@ with any other packaging system (on Linux systems, for example.) If
 the user is inside a virtual environment [1]_ then the pip
 implementation will be installed into that virtual environment.
 
-The bootstrapping process will proceed as follows:
+The bootstrap process will proceed as follows:
 
 1. The user system has Python (3.4+) installed.  In the "scripts"
    directory of the Python installation there is the bootstrap script
@@ -114,11 +122,12 @@ This installation will not perform standard pip installation steps of
 saving the file to a cache directory or updating any local database of
 installed files.
 
-The download of the pip implementation install file should be
-performed securely.  The transport from pypi.python.org will be done
-over HTTPS but the CA certificate check will most likely not be
-performed.  Therefore we will utilise the embedded signature support
-in the wheel format to validate the downloaded file.
+The download of the pip implementation install file should be performed
+securely.  The transport from pypi.python.org will be done over HTTPS but the CA
+certificate check will most likely not be performed, and therefore the download
+would still be vulnerable to active MITM attacks.  To mitigate this risk will
+use the embedded signature support in the wheel format to validate the
+downloaded file.
 
 Beyond those arguments controlling index location and download
 options, the "pip" boostrap command may support further standard pip
@@ -127,7 +136,39 @@ options for verbosity, quietness and logging.
 The "--no-install" option to the "pip" command will not affect the
 bootstrapping process.
 
-An additional new Python package will be proposed, "pypublish", which
+setuptools
+----------
+
+The deprecation of requiring setuptools for installation is an existing goal of
+the packaging comminity (TODO ref needed). Currently pip depends upon setuptools
+functionality, and it is installed by the current pip boostrap. This PEP does
+not propose installing setuptools during the new bootstrap.
+
+It is intended that before Python 3.4 is shipped the functionlity required by
+pip will be present in Python's standard library as the distlib module, and that
+pip would be modified to use that functionality when present. TODO PEP reference
+for distlib
+
+Many existing "setup.py" files require setuptools to be installed (because one
+of the first things they do is import setuptools). It is intended that pip's
+behaviour will be either:
+
+1. If setuptools is not present it can only install from wheel files and
+   sdists with 2.0+ metadata, or
+2. If setuptools is present it can also install from sdists with legacy
+   metadata and eggs
+
+By default, installing setuptools when necessary should be automatic so that
+users are not inconvenienced, but advanced users should be able to ask that it
+instead be treated as an error if no wheel is available to satisfy an
+installation request or dependency (so they don't inadvertently install
+setuptools on their production systems if they don't want to).
+
+
+Modifications to publishing packages
+------------------------------------
+
+An additional new Python package is proposed, "pypublish", which
 will be a tool for publishing packages to PyPI.  It would replace the
 current "python setup.py register" and "python setup.py upload"
 distutils commands.  Again because of the measured Python release
@@ -140,11 +181,15 @@ difficult to manage) it is desirable that those commands, and the
 accompanying keychain, be made installable and upgradeable outside of
 Python itself.
 
+The existing distutils mechanisms for package registration and upload would
+remain, though with a deprecation warning.
+
 
 Implementation
 ==============
 
-TBD
+The changes to pip required by this PEP are being tracked in that project's
+issue tracker [2]_
 
 
 Risks
@@ -156,23 +201,21 @@ current Python "pip" program is installed as "pip-python".  It is
 hoped that the Fedora community will resolve this issue by renaming
 the Perl installer.
 
-Currently pip depends upon setuptools functionality.  It is intended
-that before Python 3.4 is shipped that the required functionlity will
-be present in Python's standard library as the distlib module, and
-that pip would be modified to use that functionality when present.
-TODO PEP reference for distlib
-
 The key that is used to sign the pip implementation download might be
 compromised and this PEP currently proposes no mechanism for key
 revocation.
 
 
+
 References
 ==========
 
 .. [1] PEP 405, Python Virtual Environments
        http://www.python.org/dev/peps/pep-0405/
 
+.. [2] pip issue tracking work needed for this PEP
+       https://github.com/pypa/pip/issues/863
+
 
 Acknowledgments
 ===============