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

Guido van Rossum guido at python.org
Mon Mar 17 16:53:21 CET 2008

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.

The PEP suggests that other package managers also benefit. How do they
benefit if the bootstrap script installs setuptools? That sounds like
the bootstrap script would make setuptools the de-facto standard,
which I'd like to avoid given the politics around this topic.

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


On Mon, Mar 17, 2008 at 10:10 AM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:45 AM 3/17/2008 -0500, Martin v. Löwis wrote:
>  > > Well, it might be replaced by a protracted discussion of how the
>  > > module should work and what its API should be, but perhaps that would
>  > > be a better one to have.  :)
>  >
>  >Indeed, that's likely to happen :-)
>  >
>  > > So, the original proposal (from the previous thread about this) was
>  > > that the module be named easy_install, and that it simply downloads
>  > > setuptools and delegates to the "real" easy_install.  That way,
>  > > people can simply use "python -m easy_install ...", without worrying
>  > > about whether setuptools has been installed yet.
>  >
>  >I thought the original proposal was to install a *binary* easy_install
>  >that takes that function.
>  What do you mean by "binary"?  I thought we were talking about a
>  module.  Do you mean a script to be installed alongside Python itself
>  in e.g. /usr/bin?
>  In the original discussion, it was a module to be added alongside
>  pkg_resources, which would use pkg_resources to find and/or install
>  setuptools.  I also personally like the use of -m instead of a script
>  because it makes it quite clear that this is a Python-specific
>  installation tool, and *which* version of Python, as well, without
>  having to have easy_install-2.5, easy_install-2.6, etc.
>  > > IIRC, other package management tools such as zc.buildout and
>  > > workingenv can then be installed using easy_install.
>  > >
>  > > Any objections?  Should I revise the PEP?
>  >
>  >I'm fine with the module, but would really like to see a command
>  >line utility in addition.
>  >
>  >This, of course, would raise the issue who "owns" the easy_install
>  >script name; ideally, the script would not have to be overwritten
>  >when setuptools gets installed.
>  It won't have to.  The module will attempt to import the
>  setuptools-supplied version of easy_install, and delegate to it if
>  possible, before trying to do any download.

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

More information about the Distutils-SIG mailing list