vendorize pkg_resources; bump version

1 files changed, 8 insertions, 146 deletions

diff --git a/docs/index.rst b/docs/index.rst
index 20466f3..6149c80 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -63,72 +63,13 @@ can become a less-than-1 second "unpack from wheel".
 To build an individual wheel, run ``python setup.py bdist_wheel``.  Note that
 ``bdist_wheel`` only works with distribute (``import setuptools``); plain
 ``distutils`` does not support pluggable commands like ``bdist_wheel``.  On
-the other hand ``pip`` always runs ``setup.py`` with setuptools enabled. 
-
-File Contents
--------------
-
-Wheel files contain a folder `{distribution}-{version}.dist-info/` with
-the PEP 426 metadata (metadata version 1.3 or greater) and an additional
-file `WHEEL` with metadata about the archive itself.
-
-The root of a .whl is either purelib or platlib.
-
-If a .whl contains scripts, both purelib and platlib, or any
-other files that are not installed on sys.path, they are found in
-`{distribution}-{version}.data/{key}`.
-
-Wheel files contain metadata about the wheel format itself in
-`{distribution}-{version}/WHEEL` ::
-
-        Wheel-Version: 0.1
-        Generator: bdist_wheel 0.7
-        Root-Is-Purelib: true
-
-``Wheel-Version`` is the version number of the Wheel
-specification. ``Generator`` is the name and optionally the version of
-the software that produced the archive. ``Root-Is-Purelib`` is ``true``
-if the top level directory of the archive should be installed into
-``purelib``; otherwise the root should be installed into platlib.
-
-A wheel installer should warn if `Wheel-Version` is greater than the
-version it supports, and fail if `Wheel-Version` has a greater major
-version than the version it supports.
-
-File name convention
---------------------
-
-The wheel filename is `{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl`
-
-distribution 
-	Distribution name, e.g. ‘django’, ‘pyramid’
-version
-	PEP 386-compliant version, e.g. 1.0
-build tag
-	Optional build number. Must start with a digit. A tie breaker if two wheels have the same version. (Sorts as None if unspecified).
-implementation and language version tag
-	‘pp27’
-abi tag
-	‘cp33dmu’, 'none'
-platform tag
-	'linux_x86_64', 'any'
-	
-For example, package-1.0-py27-none-any.whl is compatible with Python 2.7
-(any Python 2.7 implementation) on any CPU architecture.
+the other hand ``pip`` always runs ``setup.py`` with setuptools enabled.
 
-The last three components of the file are called "compatibility tags."  The
-compatibility tags express the package's basic interpreter requirements, and
-are detailed in PEP 485 [http://hg.python.org/peps/file/tip/pep-0425.txt]. 
+Wheel also includes its own installer that has the advantage of working even when
+distribute has not been installed, and that can be invoked directly from wheel's
+own wheel.
 
-Ranking wheels with the same version
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Installers will sometimes have to choose the best wheel among
-several for the same version of a distribution. First, rank the
-supported implementation tags by preference, e.g. CPython might
-prefer cp33m, py33, py32. Second, choose the wheel with the smallest
-arity (``len(python_tag.split('.')) * len(abi_tag.split('.')) *
-len(platform_tag.split('.'))``). If all else fails, rebuild from source.
 
 Automatically sign wheel files
 ------------------------------
@@ -153,90 +94,11 @@ A future version of `wheel sign` will be able to choose different signing
 keys depending on the package name, in case a user wishes to reserve a more
 widely trusted key for packages they intend to distribute.
 
-Signed wheel files
-------------------
-
-Wheel files include an extended RECORD that enables
-digital signatures. PEP 376’s RECORD is altered to include
-``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding
-with no trailing = characters) as the second column instead of an
-md5sum. All possible entries are hashed, including .pyc and other
-generated files, but not RECORD. For example::
-
-        file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT_pNh2yI,3144
-        distribution-1.0.dist-info/RECORD,,
-
-RECORD.jws is not mentioned in RECORD at all. Every other file in the
-archive must have a correct sha256 digest in RECORD, or the ``wheel
-unpack`` command will fail.
-
-The signature is one or more JSON Web Signature JSON Serialization
-(JWS-JS) signatures stored in a file RECORD.jws adjacent to RECORD.
-
-A signature-aware installer can be instructed to check for a particular
-Ed25519 public key by using an extended "extras" syntax.::
-
-        # request a normal optional feature "extra", and a particular
-        # urlsafe-b64encode-nopad Ed25519 (ed25519 is in lowercase within
-        # the []) public key:
-        package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
-
-An application could distribute a `requires.txt` file with many such
-lines for all its dependencies and their public keys.  By installing
-from this file an application's users would know whether the applicaton's
-dependencies came from the correct publishers.
-
-Applications that wish to "fail open" for backwards compatibility with
-non-signature-aware installers should specify that their package provides
-the extra ``ed25519=(key)`` with no associated dependencies.
-
-Key distribution is outside the scope of this spec. Public wheel signing
-keys could be signed with the packager’s GPG key, or stored at an
-https://-protected URL.
-
-The `wheel` command line tool can create signed wheel files with
-``wheel sign wheelfile.whl``. ``wheel verify wheelfile.whl`` checks
-the signatures for internal consistency and lists the decoded signature
-headers and payloads. ``wheel unpack wheelfile.whl`` extracts the archive
-and verifies the sha256 hashes of each file. ``wheel keygen`` creates
-a keypair, remembers the signing key with the Python keyring library,
-and remembers that you trust the key in a platform-specific location;
-on Linux, ``~/.config/wheel/wheel.json``.
-
-JSON Web Signatures Extensions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Ed25519 algorithm is used as an extension to the JSON Web Signatures
-specification. Wheel uses ``alg="Ed25519"`` in the header. The ``key``
-attribute holds the signature's public JSON Web Key. For JSON Web Key /
-JSON Private Key the verifying (public) key is called ``vk`` and the
-signing (private) key is called ``sk``.
-
-Example header::
-
-    {
-      "alg": "Ed25519", 
-      "typ": "JWT", 
-      "key": {
-        "alg": "Ed25519", 
-        "vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk"
-      }
-    }
-
-A future version of wheel may omit ``typ``.
-
-Example payload::
-
-    { "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }
-
-A future version of wheel may include timestamps in the payload or in
-the signature.
-
-See http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html,
-http://self-issued.info/docs/draft-jones-json-web-signature-json-serialization-01.html,
-http://self-issued.info/docs/draft-ietf-jose-json-web-key-05.html,
-http://self-issued.info/docs/draft-jones-jose-json-private-key-00.html
+Format
+------
 
+The wheel format is being documented as PEP 427 "The Wheel Binary Package
+Format 1.0" (http://www.python.org/dev/peps/pep-0427/).
 
 Slogans
 -------