On Sat, Mar 9, 2013 at 1:28 PM, Paul Moore <p.f.mo...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
