[Distutils] distlib - installer support vs runtime support

[PJ Eby]

On Sat, Mar 9, 2013 at 1:28 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 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).

Yeah, the goal in setuptools case was to bootstrap dependency handling
by only installing one thing.  A major headache that's hitting me
right now about that is that it's basically impossible to do that and
provide SSL verification support at the same time, for versions of
Python <2.6.  So I'm pretty soon going to have to face this challenge
also, in order to get to a "secure by default" setuptools for Pythons
2.3-2.5.

Ironically, setuptools doesn't have any problems updating itself or
its dependencies, though (if it had them).  For example, if setuptools
depended on one version of distlib, and the user requested
installation of another version, this wouldn't affect setuptools at
all, because the require()s baked into its scripts would still refer
to the same distlib egg as before.

Under the pip+virtualenv paradigm, though, there aren't any eggs, so
you can't pin a single project to a dependency version, without giving
pip its own virtualenv.  And I've tried to think of a workaround to
suggest, but the challenge is that they all boil down to something
that requires you to already have distlib, in order to manage its own
installation.  ;-)

Probably the best way to work around it is to just give pip its own
virtualenv -- in the form of an executable zip file.  That is, install
pip and its dependencies to a single directory, add a __main__.py, and
zip up the whole thing with a #!python header.  Voila -- a
self-contained application you can drop on your path, and update by
just downloading a new copy of.

Of course, that only works if pip is an application, rather than a
library.  Setuptools can't take this tack because it wants to be
importable.  But if pip only needs to be runnable, not importable, you
could bundle *all* your dependencies in a single file, as long as
they're all pure Python.