[Distutils] Improving setuptools bootstrapping

[Phillip J. Eby]

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.