[Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Guido van Rossum]

On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>  >I don't think this should play games with scripts being overridden or
>  >whatever. If a bootstrap script is to be installed it should have a
>  >separate name. I'm not sure what the advantage is of a bootstrap
>  >script over "python -m bootstrap_module ..." though.
>
>  And -m also makes explicit:
>
>  1. that it's a Python-specific tool
>  2. which Python version it will apply to

Right!

>  >The PEP suggests that other package managers also benefit. How do they
>  >benefit if the bootstrap script installs setuptools?
>
>  Because those other package managers depend, in fact, on setuptools,
>  or at least pkg_resources...  which was why the original proposal was
>  to just include pkg_resources in the first place.  :)

On how much of pkg_resources do they depend? Or is that an
unanswerable question?

>  >I'd also like to avoid the specific name "easy_install" for any of
>  >this. That's a "brand name" (and a misleading one if you ask me, but
>  >that's politics again :-).
>
>  Ok, so if someone will propose a name and API for the thing, I'll
>  implement it.  (Assuming the proposed API is sane and reasonably
>  implementable, of course.)

Perhaps it can be called package_bootstrap? I don't know enough about
the required functionality to propose an API, but here goes anyway.

Would be reasonable for it to have a command line that allows you to
specify a package name, optionally a version string, and (very)
optionally a server to contact (specified as an URL?). It should
default to the highest non-experimental version that's applicable to
the current Python version (assuming there's an easy way to determine
this; I don't want it to try and download different versions until one
works). It should not handle any kind of dependency management or
package management administration.

It should be able to download a Python-only module or package and
install it into site-packages (or perhaps elsewhere if so directed via
another optional command line flag). It should support zip, tar and
tar.gz/tgz files (and perhaps tar.bz2). It should simply unpack the
zip/tar file using the zip or tar modules, and extract the
package/module into site-packages in such a way that it can be
imported directly without messing with sys.path. It should not mess
with .pth files, setup.py scripts, or eggs. If the contents of the
tar/zip file has a toplevel directory with version numbers in its name
(e.g. Django-0.96.1) it should skip that and just use the subdirectory
whose name is the "pure" package name (e.g. django).

Does this make sense? I'm happy to take push-back, this is just
something I cooked up off the top of my head based on my experience
with manually installing packages.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)