vendor pkg_resources/setuptools analysis

gistfile1.md

3 problems to be solved:

1. making pip a self-sufficient wheel installer
2. removing the headache of users being responsible for managing the setuptools build dependency themselves (most notably a pain in non-virtualenv environments),
3. the burden/fragility of supporting any pip version with any setuptools version.

solutions for #1:

1. vendor pkg_resources
2. emulate pkg_resources using the already vendored distlib (#909 )

solutions for #2 ( "setuptools-core"/"pkg_resources"/"setuptools" is a fictional/theoretical restructure)

1. vendor "setuptools-core" and have pip install "pkg_resources" for run-time entry point use
2. vendor "setuptools-core" (and rewrite the entry point system to not need pkg_resources at run-time; not sure that's possible?)
3. vendor "setuptools-core" (and rewrite just console script system to not need pkg_resources at run-time; if a project is using other entry points, they should be declaring setuptools as a dependency)
4. have get-pip.py install setuptools from wheel (assuming a solution to problem #1 is implemented)
5. dynamic install of setuptools from wheel when pip needs to install sdists (or when installing something from wheel that uses pkg_resources entry points and declares no setuptools dependency)
6. just be happy that the pip bootstrap/bundle efforts will alleviate the pain in new versions of python (by pre-installing setuptools?)

solutions for #3:

• any of the vendor solutions for #2
• for 4,5 above, have it use a pinned setuptools version.