new style of pip and setuptools vendoring

bin/compile

@@ -183,6 +183,8 @@ if [ "$FRESH_PYTHON" ] || [[ ! $(pip --version) == *$PIP_VERSION* ]]; then
   bpwatch start install_setuptools
     # Prepare it for the real world
     puts-step "Installing Setuptools ($SETUPTOOLS_VERSION)"
+    cd $ROOT_DIR/vendor/
+    tar zxf setuptools-$SETUPTOOLS_VERSION.tar.gz
     cd $ROOT_DIR/vendor/setuptools-$SETUPTOOLS_VERSION/
     python setup.py install &> /dev/null
     cd $WORKING_DIR
@@ -190,6 +192,9 @@ if [ "$FRESH_PYTHON" ] || [[ ! $(pip --version) == *$PIP_VERSION* ]]; then
 
   bpwatch start install_pip
     puts-step "Installing Pip ($PIP_VERSION)"
+
+    cd $ROOT_DIR/vendor/
+    tar zxf pip-$PIP_VERSION.tar.gz
     cd $ROOT_DIR/vendor/pip-$PIP_VERSION/
     python setup.py install &> /dev/null
     cd $WORKING_DIR

vendor/setuptools-3.6/DEVGUIDE.txt

-============================
-Quick notes for contributors
-============================
-
-Setuptools is developed using the DVCS Mercurial.
-
-Grab the code at bitbucket::
-
-    $ hg clone https://bitbucket.org/pypa/setuptools
-
-If you want to contribute changes, we recommend you fork the repository on
-bitbucket, commit the changes to your repository, and then make a pull request
-on bitbucket. If you make some changes, don't forget to:
-
-- add a note in CHANGES.txt
-
-Please commit bug-fixes against the current maintenance branch and new
-features to the default branch.
-
-You can run the tests via::
-
-    $ python setup.py test

vendor/setuptools-3.6/MANIFEST.in

-recursive-include setuptools *.py *.txt *.exe *.xml
-recursive-include tests *.py *.c *.pyx *.txt
-recursive-include setuptools/tests *.html entries*
-recursive-include setuptools/tests/svn_data *.zip
-recursive-include docs *.py *.txt *.conf *.css *.css_t Makefile indexsidebar.html
-recursive-include _markerlib *.py
-include *.py
-include *.txt
-include MANIFEST.in
-include launcher.c

vendor/setuptools-3.6/README.txt

-===============================
-Installing and Using Setuptools
-===============================
-
-.. contents:: **Table of Contents**
-
-
--------------------------
-Installation Instructions
--------------------------
-
-The recommended way to bootstrap setuptools on any system is to download
-`ez_setup.py`_ and run it using the target Python environment. Different
-operating systems have different recommended techniques to accomplish this
-basic routine, so below are some examples to get you started.
-
-Setuptools requires Python 2.6 or later. To install setuptools
-on Python 2.4 or Python 2.5, use the `bootstrap script for Setuptools 1.x
-<https://bitbucket.org/pypa/setuptools/raw/bootstrap-py24/ez_setup.py>`_.
-
-The link provided to ez_setup.py is a bookmark to bootstrap script for the
-latest known stable release.
-
-.. _ez_setup.py: https://bootstrap.pypa.io/ez_setup.py
-
-Windows 8 (Powershell)
-======================
-
-For best results, uninstall previous versions FIRST (see `Uninstalling`_).
-
-Using Windows 8 or later, it's possible to install with one simple Powershell
-command. Start up Powershell and paste this command::
-
-    > (Invoke-WebRequest https://bootstrap.pypa.io/ez_setup.py).Content | python -
-
-You must start the Powershell with Administrative privileges or you may choose
-to install a user-local installation::
-
-    > (Invoke-WebRequest https://bootstrap.pypa.io/ez_setup.py).Content | python - --user
-
-If you have Python 3.3 or later, you can use the ``py`` command to install to
-different Python versions. For example, to install to Python 3.3 if you have
-Python 2.7 installed::
-
-    > (Invoke-WebRequest https://bootstrap.pypa.io/ez_setup.py).Content | py -3 -
-
-The recommended way to install setuptools on Windows is to download
-`ez_setup.py`_ and run it. The script will download the appropriate .egg
-file and install it for you.
-
-Once installation is complete, you will find an ``easy_install`` program in
-your Python ``Scripts`` subdirectory.  For simple invocation and best results,
-add this directory to your ``PATH`` environment variable, if it is not already
-present. If you did a user-local install, the ``Scripts`` subdirectory is
-``$env:APPDATA\Python\Scripts``.
-
-
-Windows 7 (or graphical install)
-================================
-
-For Windows 7 and earlier, download `ez_setup.py`_ using your favorite web
-browser or other technique and "run" that file.
-
-
-Unix (wget)
-===========
-
-Most Linux distributions come with wget.
-
-Download `ez_setup.py`_ and run it using the target Python version. The script
-will download the appropriate version and install it for you::
-
-    > wget https://bootstrap.pypa.io/ez_setup.py -O - | python
-
-Note that you will may need to invoke the command with superuser privileges to
-install to the system Python::
-
-    > wget https://bootstrap.pypa.io/ez_setup.py -O - | sudo python
-
-Alternatively, Setuptools may be installed to a user-local path::
-
-    > wget https://bootstrap.pypa.io/ez_setup.py -O - | python - --user
-
-Unix including Mac OS X (curl)
-==============================
-
-If your system has curl installed, follow the ``wget`` instructions but
-replace ``wget`` with ``curl`` and ``-O`` with ``-o``. For example::
-
-    > curl https://bootstrap.pypa.io/ez_setup.py -o - | python
-
-
-Advanced Installation
-=====================
-
-For more advanced installation options, such as installing to custom
-locations or prefixes, download and extract the source
-tarball from `Setuptools on PyPI <https://pypi.python.org/pypi/setuptools>`_
-and run setup.py with any supported distutils and Setuptools options.
-For example::
-
-    setuptools-x.x$ python setup.py install --prefix=/opt/setuptools
-
-Use ``--help`` to get a full options list, but we recommend consulting
-the `EasyInstall manual`_ for detailed instructions, especially `the section
-on custom installation locations`_.
-
-.. _EasyInstall manual: https://pythonhosted.org/setuptools/EasyInstall
-.. _the section on custom installation locations: https://pythonhosted.org/setuptools/EasyInstall#custom-installation-locations
-
-
-Downloads
-=========
-
-All setuptools downloads can be found at `the project's home page in the Python
-Package Index`_.  Scroll to the very bottom of the page to find the links.
-
-.. _the project's home page in the Python Package Index: https://pypi.python.org/pypi/setuptools
-
-In addition to the PyPI downloads, the development version of ``setuptools``
-is available from the `Bitbucket repo`_, and in-development versions of the
-`0.6 branch`_ are available as well.
-
-.. _Bitbucket repo: https://bitbucket.org/pypa/setuptools/get/default.tar.gz#egg=setuptools-dev
-.. _0.6 branch: http://svn.python.org/projects/sandbox/branches/setuptools-0.6/#egg=setuptools-dev06
-
-Uninstalling
-============
-
-On Windows, if Setuptools was installed using an ``.exe`` or ``.msi``
-installer, simply use the uninstall feature of "Add/Remove Programs" in the
-Control Panel.
-
-Otherwise, to uninstall Setuptools or Distribute, regardless of the Python
-version, delete all ``setuptools*`` and ``distribute*`` files and
-directories from your system's ``site-packages`` directory
-(and any other ``sys.path`` directories) FIRST.
-
-If you are upgrading or otherwise plan to re-install Setuptools or Distribute,
-nothing further needs to be done. If you want to completely remove Setuptools,
-you may also want to remove the 'easy_install' and 'easy_install-x.x' scripts
-and associated executables installed to the Python scripts directory.
-
---------------------------------
-Using Setuptools and EasyInstall
---------------------------------
-
-Here are some of the available manuals, tutorials, and other resources for
-learning about Setuptools, Python Eggs, and EasyInstall:
-
-* `The EasyInstall user's guide and reference manual`_
-* `The setuptools Developer's Guide`_
-* `The pkg_resources API reference`_
-* `Package Compatibility Notes`_ (user-maintained)
-* `The Internal Structure of Python Eggs`_
-
-Questions, comments, and bug reports should be directed to the `distutils-sig
-mailing list`_.  If you have written (or know of) any tutorials, documentation,
-plug-ins, or other resources for setuptools users, please let us know about
-them there, so this reference list can be updated.  If you have working,
-*tested* patches to correct problems or add features, you may submit them to
-the `setuptools bug tracker`_.
-
-.. _setuptools bug tracker: https://bitbucket.org/pypa/setuptools/issues
-.. _Package Compatibility Notes: https://pythonhosted.org/setuptools/PackageNotes
-.. _The Internal Structure of Python Eggs: https://pythonhosted.org/setuptools/formats.html
-.. _The setuptools Developer's Guide: https://pythonhosted.org/setuptools/setuptools.html
-.. _The pkg_resources API reference: https://pythonhosted.org/setuptools/pkg_resources.html
-.. _The EasyInstall user's guide and reference manual: https://pythonhosted.org/setuptools/easy_install.html
-.. _distutils-sig mailing list: http://mail.python.org/pipermail/distutils-sig/
-
-
--------
-Credits
--------
-
-* The original design for the ``.egg`` format and the ``pkg_resources`` API was
-  co-created by Phillip Eby and Bob Ippolito.  Bob also implemented the first
-  version of ``pkg_resources``, and supplied the OS X operating system version
-  compatibility algorithm.
-
-* Ian Bicking implemented many early "creature comfort" features of
-  easy_install, including support for downloading via Sourceforge and
-  Subversion repositories.  Ian's comments on the Web-SIG about WSGI
-  application deployment also inspired the concept of "entry points" in eggs,
-  and he has given talks at PyCon and elsewhere to inform and educate the
-  community about eggs and setuptools.
-
-* Jim Fulton contributed time and effort to build automated tests of various
-  aspects of ``easy_install``, and supplied the doctests for the command-line
-  ``.exe`` wrappers on Windows.
-
-* Phillip J. Eby is the seminal author of setuptools, and
-  first proposed the idea of an importable binary distribution format for
-  Python application plug-ins.
-
-* Significant parts of the implementation of setuptools were funded by the Open
-  Source Applications Foundation, to provide a plug-in infrastructure for the
-  Chandler PIM application.  In addition, many OSAF staffers (such as Mike
-  "Code Bear" Taylor) contributed their time and stress as guinea pigs for the
-  use of eggs and setuptools, even before eggs were "cool".  (Thanks, guys!)
-
-* Tarek Ziadé is the principal author of the Distribute fork, which
-  re-invigorated the community on the project, encouraged renewed innovation,
-  and addressed many defects.
-
-* Since the merge with Distribute, Jason R. Coombs is the
-  maintainer of setuptools.  The project is maintained in coordination with
-  the Python Packaging Authority (PyPA) and the larger Python community.
-
-.. _files:

vendor/setuptools-3.6/_markerlib/__init__.py

-try:
-    import ast
-    from _markerlib.markers import default_environment, compile, interpret
-except ImportError:
-    if 'ast' in globals():
-        raise
-    def default_environment():
-        return {}
-    def compile(marker):
-        def marker_fn(environment=None, override=None):
-            # 'empty markers are True' heuristic won't install extra deps.
-            return not marker.strip()
-        marker_fn.__doc__ = marker
-        return marker_fn
-    def interpret(marker, environment=None, override=None):
-        return compile(marker)()

vendor/setuptools-3.6/_markerlib/markers.py

-# -*- coding: utf-8 -*-
-"""Interpret PEP 345 environment markers.
-
-EXPR [in|==|!=|not in] EXPR [or|and] ...
-
-where EXPR belongs to any of those:
-
-    python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
-    python_full_version = sys.version.split()[0]
-    os.name = os.name
-    sys.platform = sys.platform
-    platform.version = platform.version()
-    platform.machine = platform.machine()
-    platform.python_implementation = platform.python_implementation()
-    a free string, like '2.6', or 'win32'
-"""
-
-__all__ = ['default_environment', 'compile', 'interpret']
-
-import ast
-import os
-import platform
-import sys
-import weakref
-
-_builtin_compile = compile
-
-try:
-    from platform import python_implementation
-except ImportError:
-    if os.name == "java":
-        # Jython 2.5 has ast module, but not platform.python_implementation() function.
-        def python_implementation():
-            return "Jython"
-    else:
-        raise
-
-
-# restricted set of variables
-_VARS = {'sys.platform': sys.platform,
-         'python_version': '%s.%s' % sys.version_info[:2],
-         # FIXME parsing sys.platform is not reliable, but there is no other
-         # way to get e.g. 2.7.2+, and the PEP is defined with sys.version
-         'python_full_version': sys.version.split(' ', 1)[0],
-         'os.name': os.name,
-         'platform.version': platform.version(),
-         'platform.machine': platform.machine(),
-         'platform.python_implementation': python_implementation(),
-         'extra': None # wheel extension
-        }
-
-for var in list(_VARS.keys()):
-    if '.' in var:
-        _VARS[var.replace('.', '_')] = _VARS[var]
-
-def default_environment():
-    """Return copy of default PEP 385 globals dictionary."""
-    return dict(_VARS)
-
-class ASTWhitelist(ast.NodeTransformer):
-    def __init__(self, statement):
-        self.statement = statement # for error messages
-
-    ALLOWED = (ast.Compare, ast.BoolOp, ast.Attribute, ast.Name, ast.Load, ast.Str)
-    # Bool operations
-    ALLOWED += (ast.And, ast.Or)
-    # Comparison operations
-    ALLOWED += (ast.Eq, ast.Gt, ast.GtE, ast.In, ast.Is, ast.IsNot, ast.Lt, ast.LtE, ast.NotEq, ast.NotIn)
-
-    def visit(self, node):
-        """Ensure statement only contains allowed nodes."""
-        if not isinstance(node, self.ALLOWED):
-            raise SyntaxError('Not allowed in environment markers.\n%s\n%s' %
-                               (self.statement,
-                               (' ' * node.col_offset) + '^'))
-        return ast.NodeTransformer.visit(self, node)
-
-    def visit_Attribute(self, node):
-        """Flatten one level of attribute access."""
-        new_node = ast.Name("%s.%s" % (node.value.id, node.attr), node.ctx)
-        return ast.copy_location(new_node, node)
-
-def parse_marker(marker):
-    tree = ast.parse(marker, mode='eval')
-    new_tree = ASTWhitelist(marker).generic_visit(tree)
-    return new_tree
-
-def compile_marker(parsed_marker):
-    return _builtin_compile(parsed_marker, '<environment marker>', 'eval',
-                   dont_inherit=True)
-
-_cache = weakref.WeakValueDictionary()
-
-def compile(marker):
-    """Return compiled marker as a function accepting an environment dict."""
-    try:
-        return _cache[marker]
-    except KeyError:
-        pass
-    if not marker.strip():
-        def marker_fn(environment=None, override=None):
-            """"""
-            return True
-    else:
-        compiled_marker = compile_marker(parse_marker(marker))
-        def marker_fn(environment=None, override=None):
-            """override updates environment"""
-            if override is None:
-                override = {}
-            if environment is None:
-                environment = default_environment()
-            environment.update(override)
-            return eval(compiled_marker, environment)
-    marker_fn.__doc__ = marker
-    _cache[marker] = marker_fn
-    return _cache[marker]
-
-def interpret(marker, environment=None):
-    return compile(marker)(environment)

vendor/setuptools-3.6/docs/Makefile

-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS    =
-SPHINXBUILD   = sphinx-build
-PAPER         =
-
-# Internal variables.
-PAPEROPT_a4     = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS   = -d build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help clean html web pickle htmlhelp latex changes linkcheck
-
-help:
-	@echo "Please use \`make <target>' where <target> is one of"
-	@echo "  html      to make standalone HTML files"
-	@echo "  pickle    to make pickle files"
-	@echo "  json      to make JSON files"
-	@echo "  htmlhelp  to make HTML files and a HTML help project"
-	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
-	@echo "  changes   to make an overview over all changed/added/deprecated items"
-	@echo "  linkcheck to check all external links for integrity"
-
-clean:
-	-rm -rf build/*
-
-html:
-	mkdir -p build/html build/doctrees
-	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) build/html
-	@echo
-	@echo "Build finished. The HTML pages are in build/html."
-
-pickle:
-	mkdir -p build/pickle build/doctrees
-	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) build/pickle
-	@echo
-	@echo "Build finished; now you can process the pickle files."
-
-web: pickle
-
-json:
-	mkdir -p build/json build/doctrees
-	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) build/json
-	@echo
-	@echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
-	mkdir -p build/htmlhelp build/doctrees
-	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) build/htmlhelp
-	@echo
-	@echo "Build finished; now you can run HTML Help Workshop with the" \
-	      ".hhp project file in build/htmlhelp."
-
-latex:
-	mkdir -p build/latex build/doctrees
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) build/latex
-	@echo
-	@echo "Build finished; the LaTeX files are in build/latex."
-	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
-	      "run these through (pdf)latex."
-
-changes:
-	mkdir -p build/changes build/doctrees
-	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) build/changes
-	@echo
-	@echo "The overview file is in build/changes."
-
-linkcheck:
-	mkdir -p build/linkcheck build/doctrees
-	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) build/linkcheck
-	@echo
-	@echo "Link check complete; look for any errors in the above output " \
-	      "or in build/linkcheck/output.txt."

vendor/setuptools-3.6/docs/_templates/indexsidebar.html

-<h3>Download</h3>
-
-<p>Current version: <b>{{ version }}</b></p>
-<p>Get Setuptools from the <a href="https://pypi.python.org/pypi/setuptools"> Python Package Index</a>
-
-<h3>Questions? Suggestions? Contributions?</h3>
-
-<p>Visit the <a href="https://bitbucket.org/pypa/setuptools">Setuptools project page</a> </p>

vendor/setuptools-3.6/docs/_theme/nature/static/nature.css_t

-/**
- * Sphinx stylesheet -- default theme
- * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- */
- 
-@import url("basic.css");
- 
-/* -- page layout ----------------------------------------------------------- */
- 
-body {
-    font-family: Arial, sans-serif;
-    font-size: 100%;
-    background-color: #111111;
-    color: #555555;
-    margin: 0;
-    padding: 0;
-}
-
-div.documentwrapper {
-    float: left;
-    width: 100%;
-}
-
-div.bodywrapper {
-    margin: 0 0 0 300px;
-}
-
-hr{
-    border: 1px solid #B1B4B6;
-}
- 
-div.document {
-    background-color: #fafafa;
-}
- 
-div.body {
-    background-color: #ffffff;
-    color: #3E4349;
-    padding: 1em 30px 30px 30px;
-    font-size: 0.9em;
-}
- 
-div.footer {
-    color: #555;
-    width: 100%;
-    padding: 13px 0;
-    text-align: center;
-    font-size: 75%;
-}
- 
-div.footer a {
-    color: #444444;
-}
- 
-div.related {
-    background-color: #6BA81E;
-    line-height: 36px;
-    color: #ffffff;
-    text-shadow: 0px 1px 0 #444444;
-    font-size: 1.1em;
-}
- 
-div.related a {
-    color: #E2F3CC;
-}
-
-div.related .right {
-    font-size: 0.9em;
-}
-
-div.sphinxsidebar {
-    font-size: 0.9em;
-    line-height: 1.5em;
-    width: 300px;
-}
-
-div.sphinxsidebarwrapper{
-    padding: 20px 0;
-}
- 
-div.sphinxsidebar h3,
-div.sphinxsidebar h4 {
-    font-family: Arial, sans-serif;
-    color: #222222;
-    font-size: 1.2em;
-    font-weight: bold;
-    margin: 0;
-    padding: 5px 10px;
-    text-shadow: 1px 1px 0 white
-}
-
-div.sphinxsidebar h3 a {
-    color: #444444;
-}
-
-div.sphinxsidebar p {
-    color: #888888;
-    padding: 5px 20px;
-    margin: 0.5em 0px;
-}
- 
-div.sphinxsidebar p.topless {
-}
- 
-div.sphinxsidebar ul {
-    margin: 10px 10px 10px 20px;
-    padding: 0;
-    color: #000000;
-}
- 
-div.sphinxsidebar a {
-    color: #444444;
-}
-
-div.sphinxsidebar a:hover {
-    color: #E32E00;
-}
-
-div.sphinxsidebar input {
-    border: 1px solid #cccccc;
-    font-family: sans-serif;
-    font-size: 1.1em;
-    padding: 0.15em 0.3em;
-}
-
-div.sphinxsidebar input[type=text]{
-    margin-left: 20px;
-}
- 
-/* -- body styles ----------------------------------------------------------- */
- 
-a {
-    color: #005B81;
-    text-decoration: none;
-}
- 
-a:hover {
-    color: #E32E00;
-}
- 
-div.body h1,
-div.body h2,
-div.body h3,
-div.body h4,
-div.body h5,
-div.body h6 {
-    font-family: Arial, sans-serif;
-    font-weight: normal;
-    color: #212224;
-    margin: 30px 0px 10px 0px;
-    padding: 5px 0 5px 0px;
-    text-shadow: 0px 1px 0 white;
-    border-bottom: 1px solid #C8D5E3;
-}
- 
-div.body h1 { margin-top: 0; font-size: 200%; }
-div.body h2 { font-size: 150%; }
-div.body h3 { font-size: 120%; }
-div.body h4 { font-size: 110%; }
-div.body h5 { font-size: 100%; }
-div.body h6 { font-size: 100%; }
- 
-a.headerlink {
-    color: #c60f0f;
-    font-size: 0.8em;
-    padding: 0 4px 0 4px;
-    text-decoration: none;
-}
- 
-a.headerlink:hover {
-    background-color: #c60f0f;
-    color: white;
-}
- 
-div.body p, div.body dd, div.body li {
-    line-height: 1.8em;
-}
- 
-div.admonition p.admonition-title + p {
-    display: inline;
-}
-
-div.highlight{
-    background-color: white;
-}
-
-div.note {
-    background-color: #eeeeee;
-    border: 1px solid #cccccc;
-}
- 
-div.seealso {
-    background-color: #ffffcc;
-    border: 1px solid #ffff66;
-}
- 
-div.topic {
-    background-color: #fafafa;
-    border-width: 0;
-}
- 
-div.warning {
-    background-color: #ffe4e4;
-    border: 1px solid #ff6666;
-}
- 
-p.admonition-title {
-    display: inline;
-}
- 
-p.admonition-title:after {
-    content: ":";
-}
- 
-pre {
-    padding: 10px;
-    background-color: #fafafa;
-    color: #222222;
-    line-height: 1.5em;
-    font-size: 1.1em;
-    margin: 1.5em 0 1.5em 0;
-    -webkit-box-shadow: 0px 0px 4px #d8d8d8;
-    -moz-box-shadow: 0px 0px 4px #d8d8d8;
-    box-shadow: 0px 0px 4px #d8d8d8;
-}
- 
-tt {
-    color: #222222;
-    padding: 1px 2px;
-    font-size: 1.2em;
-    font-family: monospace;
-}
-
-#table-of-contents ul {
-    padding-left: 2em;
-}
-

vendor/setuptools-3.6/docs/_theme/nature/static/pygments.css

-.c { color: #999988; font-style: italic } /* Comment */
-.k { font-weight: bold } /* Keyword */
-.o { font-weight: bold } /* Operator */
-.cm { color: #999988; font-style: italic } /* Comment.Multiline */
-.cp { color: #999999; font-weight: bold } /* Comment.preproc */
-.c1 { color: #999988; font-style: italic } /* Comment.Single */
-.gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
-.ge { font-style: italic } /* Generic.Emph */
-.gr { color: #aa0000 } /* Generic.Error */
-.gh { color: #999999 } /* Generic.Heading */
-.gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
-.go { color: #111 } /* Generic.Output */
-.gp { color: #555555 } /* Generic.Prompt */
-.gs { font-weight: bold } /* Generic.Strong */
-.gu { color: #aaaaaa } /* Generic.Subheading */
-.gt { color: #aa0000 } /* Generic.Traceback */
-.kc { font-weight: bold } /* Keyword.Constant */
-.kd { font-weight: bold } /* Keyword.Declaration */
-.kp { font-weight: bold } /* Keyword.Pseudo */
-.kr { font-weight: bold } /* Keyword.Reserved */
-.kt { color: #445588; font-weight: bold } /* Keyword.Type */
-.m { color: #009999 } /* Literal.Number */
-.s { color: #bb8844 } /* Literal.String */
-.na { color: #008080 } /* Name.Attribute */
-.nb { color: #999999 } /* Name.Builtin */
-.nc { color: #445588; font-weight: bold } /* Name.Class */
-.no { color: #ff99ff } /* Name.Constant */
-.ni { color: #800080 } /* Name.Entity */
-.ne { color: #990000; font-weight: bold } /* Name.Exception */
-.nf { color: #990000; font-weight: bold } /* Name.Function */
-.nn { color: #555555 } /* Name.Namespace */
-.nt { color: #000080 } /* Name.Tag */
-.nv { color: purple } /* Name.Variable */
-.ow { font-weight: bold } /* Operator.Word */
-.mf { color: #009999 } /* Literal.Number.Float */
-.mh { color: #009999 } /* Literal.Number.Hex */
-.mi { color: #009999 } /* Literal.Number.Integer */
-.mo { color: #009999 } /* Literal.Number.Oct */
-.sb { color: #bb8844 } /* Literal.String.Backtick */
-.sc { color: #bb8844 } /* Literal.String.Char */
-.sd { color: #bb8844 } /* Literal.String.Doc */
-.s2 { color: #bb8844 } /* Literal.String.Double */
-.se { color: #bb8844 } /* Literal.String.Escape */
-.sh { color: #bb8844 } /* Literal.String.Heredoc */
-.si { color: #bb8844 } /* Literal.String.Interpol */
-.sx { color: #bb8844 } /* Literal.String.Other */
-.sr { color: #808000 } /* Literal.String.Regex */
-.s1 { color: #bb8844 } /* Literal.String.Single */
-.ss { color: #bb8844 } /* Literal.String.Symbol */
-.bp { color: #999999 } /* Name.Builtin.Pseudo */
-.vc { color: #ff99ff } /* Name.Variable.Class */
-.vg { color: #ff99ff } /* Name.Variable.Global */
-.vi { color: #ff99ff } /* Name.Variable.Instance */
-.il { color: #009999 } /* Literal.Number.Integer.Long */
\ No newline at end of file

vendor/setuptools-3.6/docs/_theme/nature/theme.conf

-[theme]
-inherit = basic
-stylesheet = nature.css
-pygments_style = tango

vendor/setuptools-3.6/docs/conf.py

-# -*- coding: utf-8 -*-
-#
-# Setuptools documentation build configuration file, created by
-# sphinx-quickstart on Fri Jul 17 14:22:37 2009.
-#
-# This file is execfile()d with the current directory set to its containing dir.
-#
-# The contents of this file are pickled, so don't put values in the namespace
-# that aren't pickleable (module imports are okay, they're removed automatically).
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import setup as setup_script
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.append(os.path.abspath('.'))
-
-# -- General configuration -----------------------------------------------------
-
-# Add any Sphinx extension module names here, as strings. They can be extensions
-# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = []
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix of source filenames.
-source_suffix = '.txt'
-
-# The encoding of source files.
-#source_encoding = 'utf-8'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = 'Setuptools'
-copyright = '2009-2013, The fellowship of the packaging'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = setup_script.setup_params['version']
-# The full version, including alpha/beta/rc tags.
-release = setup_script.setup_params['version']
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of documents that shouldn't be included in the build.
-#unused_docs = []
-
-# List of directories, relative to source directory, that shouldn't be searched
-# for source files.
-exclude_trees = []
-
-# The reST default role (used for this markup: `text`) to use for all documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-
-# -- Options for HTML output ---------------------------------------------------
-
-# The theme to use for HTML and HTML Help pages.  Major themes that come with
-# Sphinx are currently 'default' and 'sphinxdoc'.
-html_theme = 'nature'
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further.  For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-html_theme_path = ['_theme']
-
-# The name for this set of Sphinx documents.  If None, it defaults to
-# "<project> v<release> documentation".
-html_title = "Setuptools documentation"
-
-# A shorter title for the navigation bar.  Default is the same as html_title.
-html_short_title = "Setuptools"
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-#html_static_path = ['_static']
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-#html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-html_sidebars = {'index': 'indexsidebar.html'}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-html_use_modindex = False
-
-# If false, no index is generated.
-html_use_index = False
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it.  The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = ''
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'Setuptoolsdoc'
-
-
-# -- Options for LaTeX output --------------------------------------------------
-
-# The paper size ('letter' or 'a4').
-#latex_paper_size = 'letter'
-
-# The font size ('10pt', '11pt' or '12pt').
-#latex_font_size = '10pt'
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title, author, documentclass [howto/manual]).
-latex_documents = [
-  ('index', 'Setuptools.tex', 'Setuptools Documentation',
-   'The fellowship of the packaging', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# Additional stuff for the LaTeX preamble.
-#latex_preamble = ''
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_use_modindex = True

vendor/setuptools-3.6/docs/development.txt

--------------------------
-Development on Setuptools
--------------------------
-
-Setuptools is maintained by the Python community under the Python Packaging
-Authority (PyPA) and led by Jason R. Coombs.
-
-This document describes the process by which Setuptools is developed.
-This document assumes the reader has some passing familiarity with
-*using* setuptools, the ``pkg_resources`` module, and EasyInstall.  It
-does not attempt to explain basic concepts like inter-project
-dependencies, nor does it contain detailed lexical syntax for most
-file formats.  Neither does it explain concepts like "namespace
-packages" or "resources" in any detail, as all of these subjects are
-covered at length in the setuptools developer's guide and the
-``pkg_resources`` reference manual.
-
-Instead, this is **internal** documentation for how those concepts and
-features are *implemented* in concrete terms.  It is intended for people
-who are working on the setuptools code base, who want to be able to
-troubleshoot setuptools problems, want to write code that reads the file
-formats involved, or want to otherwise tinker with setuptools-generated
-files and directories.
-
-Note, however, that these are all internal implementation details and
-are therefore subject to change; stick to the published API if you don't
-want to be responsible for keeping your code from breaking when
-setuptools changes.  You have been warned.
-
-.. toctree::
-   :maxdepth: 1
-
-   formats
-   releases
-

vendor/setuptools-3.6/docs/index.txt

-Welcome to Setuptools' documentation!
-=====================================
-
-Setuptools is a fully-featured, actively-maintained, and stable library
-designed to facilitate packaging Python projects, where packaging includes:
-
- - Python package and module definitions
- - Distribution package metadata
- - Test hooks
- - Project installation
- - Platform-specific details
- - Python 3 support
-
-Documentation content:
-
-.. toctree::
-   :maxdepth: 2
-
-   roadmap
-   python3
-   using
-   setuptools
-   easy_install
-   pkg_resources
-   development
-   merge

vendor/setuptools-3.6/docs/merge-faq.txt

-Setuptools/Distribute Merge FAQ
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-How do I upgrade from Distribute?
-=================================
-
-Distribute specifically prohibits installation of Setuptools 0.7 from Distribute 0.6. There are then two options for upgrading.
-
-Note that after upgrading using either technique, the only option to downgrade to either version is to completely uninstall Distribute and Setuptools 0.7 versions before reinstalling an 0.6 release.
-
-Use Distribute 0.7
-------------------
-
-The PYPA has put together a compatibility wrapper, a new release of Distribute version 0.7. This package will install over Distribute 0.6.x installations and will replace Distribute with a simple wrapper that requires Setuptools 0.7 or later. This technique is experimental, but initial results indicate this technique is the easiest upgrade path.
-
-
-Uninstall
----------
-
-First, completely uninstall Distribute. Since Distribute does not have an automated installation routine, this process is manual. Follow the instructions in the README for uninstalling.
-
-
-How do I upgrade from Setuptools 0.6?
-=====================================
-
-There are no special instructions for upgrading over older versions of Setuptools. Simply use `easy_install -U` or run the latest `ez_setup.py`.
-
-Where does the merge occur?
-========================================================
-
-The merge is occurring between the heads of the default branch of Distribute and the setuptools-0.6 branch of Setuptools. The Setuptools SVN repo has been converted to a Mercurial repo hosted on Bitbucket. The work is still underway, so the exact changesets included may change, although the anticipated merge targets are Setuptools at 0.6c12 and Distribute at 0.6.35.
-
-What happens to other branches?
-========================================================
-
-Distribute 0.7 was abandoned long ago and won't be included in the resulting code tree, but may be retained for posterity in the original repo.
-
-Setuptools default branch (also 0.7 development) may also be abandoned or may be incorporated into the new merged line if desirable (and as resources allow).
-
-What history is lost/changed?
-========================================================
-
-As setuptools was not on Mercurial when the fork occurred and as Distribute did not include the full setuptools history (prior to the creation of the setuptools-0.6 branch), the two source trees were not compatible. In order to most effectively communicate the code history, the Distribute code was grafted onto the (originally private) setuptools Mercurial repo. Although this grafting maintained the full code history with names, dates, and changes, it did lose the original hashes of those changes. Therefore, references to changes by hash (including tags) are lost.
-
-Additionally, any heads that were not actively merged into the Distribute 0.6.35 release were also omitted. As a result, the changesets included in the merge repo are those from the original setuptools repo and all changesets ancestral to the Distribute 0.6.35 release.
-
-What features will be in the merged code base?
-========================================================
-
-In general, all "features" added in distribute will be included in setuptools. Where there exist conflicts or undesirable features, we will be explicit about what these limitations are. Changes that are  backward-incompatible from setuptools 0.6 to distribute will likely be  removed, and these also will be well documented.
-
-Bootstrapping scripts (ez_setup/distribute_setup) and docs, as with  distribute, will be maintained in the repository and built as part of  the release process. Documentation and bootstrapping scripts will be  hosted at python.org, as they are with distribute now. Documentation at  telecommunity will be updated to refer or redirect to the new, merged  docs.
-
-On  the whole, the merged setuptools should be largely compatible with the  latest releases of both setuptools and distribute and will be an easy  transition for users of either library.
-
-Who is invited to contribute? Who is excluded?
-========================================================
-
-While we've worked privately to initiate this merge due to the potential sensitivity of the topic, no one is excluded from this effort. We invite all members of the  community, especially those most familiar with Python packaging and its challenges to join us in the effort.
-
-We have lots of  ideas for how we'd like to improve the codebase, release process,  everything.  Like distribute, the post-merge setuptools will have its  source hosted on bitbucket.  (So if you're currently a distribute  contributor, about the only thing that's going to change is the URL of  the repository you follow.)  Also like distribute, it'll support Python  3, and hopefully we'll soon merge Vinay Sajip's patches to make it run  on Python 3 without needing 2to3 to be run on the code first.
-
-While we've worked privately to initiate this merge due to the potential sensitivity of the topic, no one is excluded from this effort. We invite all members of the community, especially those most familiar with Python packaging and its challenges to join us in the effort.
-
-Why Setuptools and not Distribute or another name?
-========================================================
-
-We do, however,  understand that this announcement might be unsettling for some.  The  setuptools name has been subjected to a lot of deprecation in recent  years, so the idea that it will now be the preferred name instead of distribute might be somewhat difficult or disorienting for some.   We considered use of another name (Distribute or an entirely new name),  but that would serve to only complicate matters further. Instead, our goal is to simplify the packaging landscape but without losing any hard-won advancements.  We hope  that the people who worked to spread the first message will be equally  enthusiastic about spreading the new one, and we especially look forward to seeing the new posters and slogans celebrating setuptools.
-
-What is the timeframe of release?
-========================================================
-
-There are no hard timeframes for any of this effort, although progress is underway and a draft merge is underway and being tested privately.   As an unfunded volunteer effort, our time to put in on it is limited,  and we've both had some recent health and other challenges that have  made working on this difficult, which in part explains why we haven't met our original deadline of a completed merge before PyCon.
-
-The final Setuptools 0.7 was cut on June 1, 2013 and will be released to PyPI shortly thereafter.
-
-What version number can I expect for the new release?
-========================================================
-
-The new release will roughly follow the previous trend for setuptools and release the new release as 0.7. This number is somewhat arbitrary, but we wanted something other than 0.6 to distinguish it from its ancestor forks but not 1.0 to avoid putting too much emphasis on the release itself and to focus on merging the functionality. In the future, the project will likely adopt a versioning scheme similar to semver to convey semantic meaning about the release in the version number.

vendor/setuptools-3.6/docs/merge.txt

-Merge with Distribute
-~~~~~~~~~~~~~~~~~~~~~
-
-In 2013, the fork of Distribute was merged back into Setuptools. This
-document describes some of the details of the merge.
-
-.. toctree::
-   :maxdepth: 2
-
-   merge-faq
-
-Process
-=======
-
-In order to try to accurately reflect the fork and then re-merge of the
-projects, the merge process brought both code trees together into one
-repository and grafted the Distribute fork onto the Setuptools development
-line (as if it had been created as a branch in the first place).
-
-The rebase to get distribute onto setuptools went something like this::
-
-    hg phase -d -f -r 26b4c29b62db
-    hg rebase -s 26b4c29b62db -d 7a5cf59c78d7
-
-The technique required a late version of mercurial (2.5) to work correctly.
-
-The only code that was included was the code that was ancestral to the public
-releases of Distribute 0.6. Additionally, because Setuptools was not hosted
-on Mercurial at the time of the fork and because the Distribute fork did not
-include a complete conversion of the Setuptools history, the Distribute
-changesets had to be re-applied to a new, different conversion of the
-Setuptools SVN repository. As a result, all of the hashes have changed.
-
-Distribute was grafted in a 'distribute' branch and the 'setuptools-0.6'
-branch was targeted for the merge. The 'setuptools' branch remains with
-unreleased code and may be incorporated in the future.
-
-Reconciling Differences
-=======================
-
-There were both technical and philosophical differences between Setuptools
-and Distribute. To reconcile these differences in a manageable way, the
-following technique was undertaken:
-
-Create a 'Setuptools-Distribute merge' branch, based on a late release of
-Distribute (0.6.35). This was done with a00b441856c4.
-
-In that branch, first remove code that is no longer relevant to
-Setuptools (such as the setuptools patching code).
-
-Next, in the the merge branch, create another base from at the point where the
-fork occurred (such that the code is still essentially an older but pristine
-setuptools). This base can be found as 955792b069d0. This creates two heads
-in the merge branch, each with a basis in the fork.
-
-Then, repeatedly copy changes for a
-single file or small group of files from a late revision of that file in the
-'setuptools-0.6' branch (1aae1efe5733 was used) and commit those changes on
-the setuptools-only head. That head is then merged with the head with
-Distribute changes. It is in this Mercurial
-merge operation that the fundamental differences between Distribute and
-Setuptools are reconciled, but since only a single file or small set of files
-are used, the scope is limited.
-
-Finally, once all the challenging files have been reconciled and merged, the
-remaining changes from the setuptools-0.6 branch are merged, deferring to the
-reconciled changes (a1fa855a5a62 and 160ccaa46be0).
-
-Originally, jaraco attempted all of this using anonymous heads in the
-Distribute branch, but later realized this technique made for a somewhat
-unclear merge process, so the changes were re-committed as described above
-for clarity. In this way, the "distribute" and "setuptools" branches can
-continue to track the official Distribute changesets.
-
-Concessions
-===========
-
-With the merge of Setuptools and Distribute, the following concessions were
-made:
-
-Differences from setuptools 0.6c12:
-
-Major Changes
--------------
-
-* Python 3 support.
-* Improved support for GAE.
-* Support `PEP-370 <http://www.python.org/dev/peps/pep-0370/>`_ per-user site
-  packages.
-* Sort order of Distributions in pkg_resources now prefers PyPI to external
-  links (Distribute issue 163).
-* Python 2.4 or greater is required (drop support for Python 2.3).
-
-Minor Changes
--------------
-
-* Wording of some output has changed to replace contractions with their
-  canonical form (i.e. prefer "could not" to "couldn't").
-* Manifest files are only written for 32-bit .exe launchers.
-
-Differences from Distribute 0.6.36:
-
-Major Changes
--------------
-
-* The _distribute property of the setuptools module has been removed.
-* Distributions are once again installed as zipped eggs by default, per the
-  rationale given in `the seminal bug report
-  <http://bugs.python.org/setuptools/issue33>`_ indicates that the feature
-  should remain and no substantial justification was given in the `Distribute
-  report <https://bitbucket.org/tarek/distribute/issue/19/>`_.
-
-Minor Changes
--------------
-
-* The patch for `#174 <https://bitbucket.org/tarek/distribute/issue/174>`_
-  has been rolled-back, as the comment on the ticket indicates that the patch
-  addressed a symptom and not the fundamental issue.
-* ``easy_install`` (the command) once again honors setup.cfg if found in the
-  current directory. The "mis-behavior" characterized in `#99
-  <https://bitbucket.org/tarek/distribute/issue/99>`_ is actually intended
-  behavior, and no substantial rationale was given for the deviation.

vendor/setuptools-3.6/docs/python3.txt

-=====================================================
-Supporting both Python 2 and Python 3 with Setuptools
-=====================================================
-
-Starting with Distribute version 0.6.2 and Setuptools 0.7, the Setuptools
-project supported Python 3. Installing and
-using setuptools for Python 3 code works exactly the same as for Python 2
-code, but Setuptools also helps you to support Python 2 and Python 3 from
-the same source code by letting you run 2to3 on the code as a part of the
-build process, by setting the keyword parameter ``use_2to3`` to True.
-
-
-Setuptools as help during porting
-=================================
-
-Setuptools can make the porting process much easier by automatically running
-2to3 as a part of the test running. To do this you need to configure the
-setup.py so that you can run the unit tests with ``python setup.py test``.
-
-See :ref:`test` for more information on this.
-
-Once you have the tests running under Python 2, you can add the use_2to3
-keyword parameters to setup(), and start running the tests under Python 3.
-The test command will now first run the build command during which the code
-will be converted with 2to3, and the tests will then be run from the build
-directory, as opposed from the source directory as is normally done.
-
-Setuptools will convert all Python files, and also all doctests in Python
-files. However, if you have doctests located in separate text files, these
-will not automatically be converted. By adding them to the
-``convert_2to3_doctests`` keyword parameter Setuptools will convert them as
-well.
-
-By default, the conversion uses all fixers in the ``lib2to3.fixers`` package.
-To use additional fixers, the parameter ``use_2to3_fixers`` can be set
-to a list of names of packages containing fixers. To exclude fixers, the
-parameter ``use_2to3_exclude_fixers`` can be set to fixer names to be
-skipped.
-
-A typical setup.py can look something like this::
-
-    from setuptools import setup
-
-    setup(
-        name='your.module',
-        version = '1.0',
-        description='This is your awesome module',
-        author='You',
-        author_email='your@email',
-        package_dir = {'': 'src'},
-        packages = ['your', 'you.module'],
-        test_suite = 'your.module.tests',
-        use_2to3 = True,
-        convert_2to3_doctests = ['src/your/module/README.txt'],
-        use_2to3_fixers = ['your.fixers'],
-        use_2to3_exclude_fixers = ['lib2to3.fixes.fix_import'],
-    )
-
-Differential conversion
------------------------
-
-Note that a file will only be copied and converted during the build process
-if the source file has been changed. If you add a file to the doctests
-that should be converted, it will not be converted the next time you run
-the tests, since it hasn't been modified. You need to remove it from the
-build directory. Also if you run the build, install or test commands before
-adding the use_2to3 parameter, you will have to remove the build directory
-before you run the test command, as the files otherwise will seem updated,
-and no conversion will happen.
-
-In general, if code doesn't seem to be converted, deleting the build directory
-and trying again is a good saferguard against the build directory getting
-"out of sync" with the source directory.
-
-Distributing Python 3 modules
-=============================
-
-You can distribute your modules with Python 3 support in different ways. A
-normal source distribution will work, but can be slow in installing, as the
-2to3 process will be run during the install. But you can also distribute
-the module in binary format, such as a binary egg. That egg will contain the
-already converted code, and hence no 2to3 conversion is needed during install.
-
-Advanced features
-=================
-
-If you don't want to run the 2to3 conversion on the doctests in Python files,
-you can turn that off by setting ``setuptools.use_2to3_on_doctests = False``.
-
-Note on compatibility with older versions of setuptools
-=======================================================
-
-Setuptools earlier than 0.7 does not know about the new keyword parameters to
-support Python 3.
-As a result it will warn about the unknown keyword parameters if you use
-those versions of setuptools instead of Distribute under Python 2. This output
-is not an error, and
-install process will continue as normal, but if you want to get rid of that
-error this is easy. Simply conditionally add the new parameters into an extra
-dict and pass that dict into setup()::
-
-    from setuptools import setup
-    import sys
-
-    extra = {}
-    if sys.version_info >= (3,):
-        extra['use_2to3'] = True
-        extra['convert_2to3_doctests'] = ['src/your/module/README.txt']
-        extra['use_2to3_fixers'] = ['your.fixers']
-
-    setup(
-        name='your.module',
-        version = '1.0',
-        description='This is your awesome module',
-        author='You',
-        author_email='your@email',
-        package_dir = {'': 'src'},
-        packages = ['your', 'you.module'],
-        test_suite = 'your.module.tests',
-        **extra
-    )
-
-This way the parameters will only be used under Python 3, where Distribute or
-Setuptools 0.7 or later is required.

vendor/setuptools-3.6/docs/releases.txt

-===============
-Release Process
-===============
-
-In order to allow for rapid, predictable releases, Setuptools uses a
-mechanical technique for releases. The release script, ``release.py`` in the
-repository, defines the details of the releases, and is executed by the
-`jaraco.packaging <https://bitbucket.org/jaraco/jaraco.packaging>`_ release
-module. The script does some checks (some interactive) and fully automates
-the release process.
-
-A Setuptools release manager must have maintainer access on PyPI to the
-project and administrative access to the BitBucket project.
-
-Release Managers
-----------------
-
-Currently, the project has one release manager, Jason R. Coombs.

vendor/setuptools-3.6/docs/roadmap.txt

-=======
-Roadmap
-=======
-
-Setuptools is primarily in maintenance mode. The project attempts to address
-user issues, concerns, and feature requests in a timely fashion.

vendor/setuptools-3.6/docs/using.txt

-================================
-Using Setuptools in your project
-================================
-
-To use Setuptools in your project, the recommended way is to ship
-`ez_setup.py` alongside your `setup.py` script and call
-it at the very beginning of `setup.py` like this::
-
-    from ez_setup import use_setuptools
-    use_setuptools()

vendor/setuptools-3.6/easy_install.py

-"""Run the EasyInstall command"""
-
-if __name__ == '__main__':
-    from setuptools.command.easy_install import main
-    main()

vendor/setuptools-3.6/release.py

-"""
-Setuptools is released using 'jaraco.packaging.release'. To make a release,
-install jaraco.packaging and run 'python -m jaraco.packaging.release'
-"""
-
-import re
-import os
-import subprocess
-
-import pkg_resources
-
-pkg_resources.require('jaraco.packaging>=2.0')
-pkg_resources.require('wheel')
-
-
-def before_upload():
-    _linkify('CHANGES.txt', 'CHANGES (links).txt')
-    BootstrapBookmark.add()
-
-
-def after_push():
-    os.remove('CHANGES (links).txt')
-    BootstrapBookmark.push()
-
-files_with_versions = (
-    'ez_setup.py', 'setuptools/version.py',
-)
-
-# bdist_wheel must be included or pip will break
-dist_commands = 'sdist', 'bdist_wheel'
-
-test_info = "Travis-CI tests: http://travis-ci.org/#!/jaraco/setuptools"
-
-os.environ["SETUPTOOLS_INSTALL_WINDOWS_SPECIFIC_FILES"] = "1"
-
-link_patterns = [
-    r"(Issue )?#(?P<issue>\d+)",
-    r"Pull Request ?#(?P<pull_request>\d+)",
-    r"Distribute #(?P<distribute>\d+)",
-    r"Buildout #(?P<buildout>\d+)",
-    r"Old Setuptools #(?P<old_setuptools>\d+)",
-    r"Jython #(?P<jython>\d+)",
-    r"Python #(?P<python>\d+)",
-]
-
-issue_urls = dict(
-    pull_request='https://bitbucket.org'
-        '/pypa/setuptools/pull-request/{pull_request}',
-    issue='https://bitbucket.org/pypa/setuptools/issue/{issue}',
-    distribute='https://bitbucket.org/tarek/distribute/issue/{distribute}',
-    buildout='https://github.com/buildout/buildout/issues/{buildout}',
-    old_setuptools='http://bugs.python.org/setuptools/issue{old_setuptools}',
-    jython='http://bugs.jython.org/issue{jython}',
-    python='http://bugs.python.org/issue{python}',
-)
-
-
-def _linkify(source, dest):
-    pattern = '|'.join(link_patterns)
-    with open(source) as source:
-        out = re.sub(pattern, replacer, source.read())
-    with open(dest, 'w') as dest:
-        dest.write(out)
-
-
-def replacer(match):
-    text = match.group(0)
-    match_dict = match.groupdict()
-    for key in match_dict:
-        if match_dict[key]:
-            url = issue_urls[key].format(**match_dict)
-            return "`{text} <{url}>`_".format(text=text, url=url)
-
-class BootstrapBookmark:
-    name = 'bootstrap'
-
-    @classmethod
-    def add(cls):
-        cmd = ['hg', 'bookmark', '-i', cls.name, '-f']
-        subprocess.Popen(cmd)
-
-    @classmethod
-    def push(cls):
-        """
-        Push the bootstrap bookmark
-        """
-        push_command = ['hg', 'push', '-B', cls.name]
-        # don't use check_call here because mercurial will return a non-zero
-        # code even if it succeeds at pushing the bookmark (because there are
-        # no changesets to be pushed). !dm mercurial
-        subprocess.call(push_command)

vendor/setuptools-3.6/setup.cfg

-[egg_info]
-tag_build = 
-tag_svn_revision = 0
-tag_date = 0
-
-[aliases]
-release = egg_info -RDb ''
-source = register sdist binary
-binary = bdist_egg upload --show-response
-
-[build_sphinx]
-source-dir = docs/
-build-dir = docs/build
-all_files = 1
-
-[upload_docs]
-upload-dir = docs/build/html
-
-[sdist]
-formats = gztar zip
-
-[wheel]
-universal = 1
-
-[pytest]
-addopts = --ignore tests/manual_test.py --ignore tests/shlib_test
-

vendor/setuptools-3.6/setuptools/command/__init__.py

-__all__ = [
-    'alias', 'bdist_egg', 'bdist_rpm', 'build_ext', 'build_py', 'develop',
-    'easy_install', 'egg_info', 'install', 'install_lib', 'rotate', 'saveopts',
-    'sdist', 'setopt', 'test', 'install_egg_info', 'install_scripts',
-    'register', 'bdist_wininst', 'upload_docs',
-]
-
-from setuptools.command import install_scripts
-import sys
-
-from distutils.command.bdist import bdist
-
-if 'egg' not in bdist.format_commands:
-    bdist.format_command['egg'] = ('bdist_egg', "Python .egg file")
-    bdist.format_commands.append('egg')
-
-del bdist, sys

vendor/setuptools-3.6/setuptools/command/bdist_rpm.py

-import distutils.command.bdist_rpm as orig
-
-class bdist_rpm(orig.bdist_rpm):
-    """
-    Override the default bdist_rpm behavior to do the following:
-
-    1. Run egg_info to ensure the name and version are properly calculated.
-    2. Always run 'install' using --single-version-externally-managed to
-       disable eggs in RPM distributions.
-    3. Replace dash with underscore in the version numbers for better RPM
-       compatibility.
-    """
-
-    def run(self):
-        # ensure distro name is up-to-date
-        self.run_command('egg_info')
-
-        orig.bdist_rpm.run(self)
-
-    def _make_spec_file(self):
-        version = self.distribution.get_version()
-        rpmversion = version.replace('-','_')
-        spec = orig.bdist_rpm._make_spec_file(self)
-        line23 = '%define version ' + version
-        line24 = '%define version ' + rpmversion
-        spec = [
-            line.replace(
-                "Source0: %{name}-%{version}.tar",
-                "Source0: %{name}-%{unmangled_version}.tar"
-            ).replace(
-                "setup.py install ",
-                "setup.py install --single-version-externally-managed "
-            ).replace(
-                "%setup",
-                "%setup -n %{name}-%{unmangled_version}"
-            ).replace(line23, line24)
-            for line in spec
-        ]
-        insert_loc = spec.index(line24) + 1
-        unmangled_version = "%define unmangled_version " + version
-        spec.insert(insert_loc, unmangled_version)
-        return spec