[Distutils] distlib - installer support vs runtime support

Paul Moore p.f.moore at gmail.com
Sat Mar 9 19:28:44 CET 2013


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).


More information about the Distutils-SIG mailing list