As part of a discussion on a pip issue, it was noted that if pip depends on distlib for installer capabilities (e.g., locators, wheel installation, version and requirement parsing and matching, etc) then the user needs distlib installed as well as pip. That shouldn't be an issue for an end user, any more than having pip itself installed would be.
However, there are some capabilites of distlib (notably the "exports" functionality that replaces setuptools' entry points) that are intended to be used at runtime, by the end user. (I suspect, but haven't checked, that the exe wrapper functionality depends on exports as well - it certainly does in setuptools). That means that the end user *is* affected by the fact that pip depends on distlib. For example, if the user needs a later version of distlib, it's quite likely that he won't be able to "pip install" it, as pip typically has trouble upgrading its own dependencies (for obvious reasons...) Would it be worth considering splitting distlib into two separate parts - one that is intended solely for writers of installers and similar tools, and another for "runtime support" functions that end users would use? It may not be a practical thing to achieve, but it would be worth at least understanding the trade-offs involved. Paul. PS The same issue exists in setuptools, but as far as I am aware, setuptools was deliberately designed to provide both the installation tools and runtime support in the one package. (And IIUC, even with setuptools, pkg_resources is the only component that includes runtime support, so in theory it is possible to split the two parts up). _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
