At 01:06 PM 9/5/2006 -0700, Jim Fulton wrote:

On Sep 1, 2006, at 7:35 PM, Phillip J. Eby wrote: ...

...

Right now, ez_setup.py is used for two purposes. First, you can include it in a source package in order to be able to use setuptools. Second, it's also used as a way of installing setuptools in a standalone setting. ... So, perhaps we should move to doing something like this: when you run a setup.py that's using ez_setup(), and it appears necessary to download/install setuptools, a message is displayed, something like:

....

...

This would reduce ez_setup.py to hardly any code at all.

Pros: * Net-less installs are less painful * Users don't get surprised by "setup.py install" trying to access the net * No version skew or missing version issues * Users can install system packages (RPM, .exe, etc.) of setuptools

Cons: * Manual step for new setuptools adopters (but who's left?) * Might break setuptools-wrapping programs (like zc.buildout and Enstaller) if they rely on ez_setup * Developers might not want to switch to this new approach, if they feel the manual step is unwieldy

Does anybody have any thoughts on this, one way or the other?

+1

However, this only addresses the first use case above. I still like ez_setup for the second use case.

Well, the theory behind this approach for the second case is that if we have options to install setuptools via system-specific packages (RPM, .deb, .exe, etc.), then this could be a required prerequisite, not unlike installing Python itself.

In particular, the zc.buildout bootstrap script lets ez_setup do most of it's work. It downloads a fresh copy of ez_setup and uses it to download setuptools and zc.buildout. Part of what makes this work is the fact that ez_setup has a well-known URL, so my bootstrap script, http://svn.zope.org/zc.buildout/trunk/bootstrap/bootstrap.py? view=auto can be pretty stupid and minimal.

True; of course, if setuptools is a standard system package, it's not much different than requiring Python to be installed first. And if setuptools becomes part of Python in 2.6, the issue goes away altogether.

Of course, if ez_setup went away, I'd cope. :)

I've thought about changing ez_setup to use the PyPI XML-RPC interface to find the right download file, as that would remedy certain issues -- at the cost of still being problematic for network-deprived installations. It may be that the complete strategy needs to be to make platform-specific binary installation packages available, and for the bundling scenario change ez_setup to direct people to the binaries, but also offer a command-line option to request a download. For the standalone scenario, we would of course download. And the download should use PyPI's XML-RPC to select the latest stable version.