[Distutils] Setuptools for Python 2.5

[Phillip J. Eby]

At 07:27 AM 9/21/2006 -0400, Kevin Dangoor wrote:
>On Sep 20, 2006, at 9:47 PM, Phillip J. Eby wrote:
>
>>Thus, I'm more inclined to make it *dumber* in future, not
>>smarter.  On
>>Unix platforms, with Python 2.4 and up, one could do something like:
>>
>>      PYTHONPATH=setuptools*.egg python -m easy_install -a
>>setuptools*.egg
>
>This may not be a bad idea for setuptools, but I'm actually creating
>a front-end installer for TurboGears (that currently includes
>ez_setup.py in the file). I realized that TG's install docs were
>dealing with things that could easily be checked at install time.
>(Python version, are you in a directory with a "turbogears"
>subdirectory, may even check things like "are you running random
>linux distro X that has problem Y?)
>
>This script should ultimately eliminate our "having trouble
>installing doc?" and reduce the TurboGears installation instructions to:
>
>1. get python
>2. download tgsetup.py
>3. run it
>
>This deals with having an appropriately set find-links,

You can specify those in setup(dependency_links=[...]) now, remember?

The new instructions under the proposed regime could be:

1. get python
2. install a recent setuptools
3. easy_install turbogears

Step 2 would expand to downloading either an .exe, .src.rpm, .tgz, or .egg, 
and peforming the normal installation incantation upon it.  (Where for the 
.egg, it'd be "sh setuptools-whatever.egg".)


>being able to
>upgrade setuptools as needed, and will also handle offline install
>packages when we have them.
>
>I think a lot of this is because setuptools is still new and not yet
>a standard part of Python. Once we're past the bootstrapping period,
>the need for this script will likely disappear entirely.
>
>But, for now, it's nice having a customized script to give people a
>single, simple install command for first time installs and upgrades.
>
>(You might be wondering how this relates to your message. D'oh! My
>point is actually that I have a use case for ez_setup.py as it
>currently stands.)

Not exactly, you have a need for something that's *like* ez_setup.py.

Hm.  Here's an interesting thought.  Suppose bdist_egg could slap a /bin/sh 
header on any egg it built, that used python -c to invoke an entry 
point?  Then, you could have a turbogears egg that could be invoked with 
"sh turbogears-whatever.egg" to run its install script.

And for Windows, perhaps we could have setuptools install a file 
association for .egg that converts the egg into a bdist_wininst and runs 
it, thus giving Windows users an easy uninstall capability.  It could 
actually display the dependencies and prompt to download them or do so 
automatically.  Or it could just run the same entry point, or look for a 
gui_installer entry point instead of a shell_installer entry point.

Hm.  Interesting ideas to ponder there, especially since easy_install could 
in principle honor those options as well.

I realize that both you and Jim Fulton want to have single-script bootstrap 
options for your projects, but I suggest that this approach will bring you 
pain in the long run, as it has with ez_setup.py.  More precisely, it 
causes pain in the ez_setup.py case because it requires too much smarts to 
identify *what* setuptools to install.

With setuptools close to 0.6 final, however, there's a good chance that it 
will soon be reasonable to expect people to install it along with Python, 
e.g. as a system package.  At that point, TurboGears and zc.buildout can 
both reasonably use easy_install rather than ez_setup.py.