[Distutils] Improving setuptools bootstrapping

[Rick Ratzel]

   Phillip,

 Regarding your concern about breaking setuptools-wrapping programs, don't worry
about Enstaller.  Yes, it does depend on the functionality that ez_setup.py
currently provides at the moment, but the bootstrap code is easily changed to
grab and install setuptools using other means (we have Enstaller handling eggs
of everything from wxPython on Linux to MinGW on Windows, so I'm sure a change
for something like this won't be a problem ;).

 We can have Enstaller default to finding the latest setuptools available if one
isn't installed, or a specific version if the user requests it.  A nice feature
of Enstaller will be that another con you mentioned--the extra manual step for
new setuptools adopters--also won't be an issue.

>   Date: Fri, 01 Sep 2006 19:35:16 -0400
>   From: "Phillip J. Eby" <pje at telecommunity.com>
>
>   So, I've been giving some thought to how setuptools does its bootstrap 
>   installation.
>
>   One potentially-significant problem is that people are often installing 
>   older versions, because of old copies of ez_setup.py being distributed in 
>   people's packages.
>
>   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.
>
>   In both cases, there are two possibilities regarding the target machine: it 
>   may have network access, or it may not.  If it does have access, the 
>   current approaches basically work okay, except for the versioning 
>   issue.  If network access isn't available, however, it annoys users who are 
>   trying to install a setuptools-based package who don't already have 
>   setuptools.  (Thus creating a bad impression for both setuptools *and* the 
>   package using it.)
>
>   This isn't likely to remain a problem in the long term.  As setuptools 
>   stabilizes, it will be more likely that the user already has a current and 
>   stable setuptools version installed.  A later version of Python might even 
>   bundle it, and it's also relatively easy to create system packages of 
>   setuptools now.
>
>   For example, I could go back to building .exe installers for Windows, and 
>   perhaps throw in Linux RPMs as well.  (And perhaps get contributed Mac OS 
>   packages too.)  Back when the current ez_setup.py system was created, this 
>   wasn't an option because system packages of eggs weren't well-supported, 
>   and version conflicts could occur if you tried to also install the egg 
>   version of something.  But none of these things are issues any more.
>
>   So it's possible that we could start phasing out ez_setup's automatic 
>   downloading, in favor of simply requesting that setuptools be installed first.
>
>   The advantage is that ez_setup would become simpler and more stable, 
>   without version skew in its distributed versions.  The disadvantage is that 
>   it requires an extra step to install, which might discourage user or 
>   developer adoption.
>
>   But adoption appears to be quite widespread now; the Cheeseshop shows tens 
>   of thousands of downloads of setuptools 0.6c1 alone!
>
>   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:
>
>   ----------------------------------------------------------------
>   setuptools >= 0.6c1 not found
>
>   Please install or upgrade the setuptools package before running
>   this script; see http://cheeseshop.python.org/pypi/setuptools
>   for downloads.
>   ----------------------------------------------------------------
>
>   If there's a version of setuptools already on the machine, the message 
>   could also add something like this at the end:
>
>      You may be able to upgrade your current installation of
>      setuptools using 'easy_install -U setuptools'.
>
>   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?
>
>   _______________________________________________
>   Distutils-SIG maillist  -  Distutils-SIG at python.org
>   http://mail.python.org/mailman/listinfo/distutils-sig
>
>

-- 
Rick Ratzel - Enthought, Inc.
515 Congress Avenue, Suite 2100 - Austin, Texas 78701
512-536-1057 x229 - Fax: 512-536-1059
http://www.enthought.com