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.

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 :-). --Guido On Mon, Mar 17, 2008 at 10:10 AM, Phillip J. Eby 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/)