Skip to content

Instantly share code, notes, and snippets.

Created Jul 19, 2013
What would you like to do?
vendor pkg_resources/setuptools analysis

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 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment