Re: [Distutils] Setuptools for Python 2.5
On 21/09/2006 10:04 AM, Phillip J. Eby wrote:
At 03:07 PM 9/16/2006 +1000, John Machin wrote:
I tried to use 2.5c1 to run ez_setup.py; it looked in the cheeseshop, but terminated rather ungracefully with an HTTP 404 error.
0.6c3 is in the Cheeseshop now, with support for Python 2.5.
Thanks, Phillip. I've got it now, but needed to get over another hurdle, which was that ez_setup.py contains hard-coded egg names and md5 checksums, and thus seems to need to be fetched (manually, not exactly "ez") from your website each time the world changes. Using the old version of ez_setup (which I had used successfully to get setuptools for python 2.4 & 2.3), the command \python25\python ez_setup.py gave HTTP error 404. Shouldn't it just find the latest 2.5-compatible egg in the Cheeseshop? Or should I be using some non-default args? Shouldn't it be a little more helpful than "404" if it can't find a suitable egg?
I think it would be a good idea to have a note on the website about when a 2.5-compatible version of setuptools will be available. Also (unless I've missed it), there is no mention of a preferred e-mail address for questions, bug reports, suggestions, ...
Actually, it's at the end of the setuptools manual:
http://peak.telecommunity.com/DevCenter/setuptools#mailing-list
Thanks; I must have skipped the table of contents and just read serially until I got to the release notes and then baled out :-) Cheers, John
At 11:00 AM 9/21/2006 +1000, John Machin wrote:
On 21/09/2006 10:04 AM, Phillip J. Eby wrote:
At 03:07 PM 9/16/2006 +1000, John Machin wrote:
I tried to use 2.5c1 to run ez_setup.py; it looked in the cheeseshop, but terminated rather ungracefully with an HTTP 404 error. 0.6c3 is in the Cheeseshop now, with support for Python 2.5.
Thanks, Phillip. I've got it now, but needed to get over another hurdle, which was that ez_setup.py contains hard-coded egg names and md5 checksums, and thus seems to need to be fetched (manually, not exactly "ez") from your website each time the world changes.
Using the old version of ez_setup (which I had used successfully to get setuptools for python 2.4 & 2.3), the command \python25\python ez_setup.py gave HTTP error 404.
Shouldn't it just find the latest 2.5-compatible egg in the Cheeseshop?
That would be nice. However, it's actually getting to the point where we should probably just distribute RPMs, bdist_wininst, and other installers for the thing. I am tempted, however, to make ez_setup.py a little smarter in future. Unfortunately, the smarter it gets, the more it doesn't know. That is, the more sophisticated that ez_setup.py gets, the more things that can go wrong. 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 And it would self-install. So, under 2.4+ and Mac/Linux/etc., there'd be no need for ez_setup.py. For Windows, I could go back to distributing a bdist_wininst version. For Python 2.3 on Unix, alas, a more eclectic initial command is required: PYTHONPATH=setuptools*.egg python -c "from easy_install import main; main()" -a setuptools*.egg And that would be the end of ez_setup.py for normal users. And the ez_setup that gets bundled with setuptools-based packages could just tell the user to go download the egg or .exe from the CheeseShop. Hmm. You know, I could probably stick a little /bin/sh script on the front of the eggs to allow them to be run from Unix, almost as if they were shell archives. You would just run something like: sh setuptools-0.6c4-py2.3.egg in order to install it on Unix. Then, I'd effectively have a universal installer for non-Windows platforms, and an .exe installer for Windows. (I could also start releasing source RPMs for setuptools as well.) And ez_setup.py would go back to being a packager-only tool. This would be a lot of documentation change, but it might well be worth it.
Shouldn't it be a little more helpful than "404" if it can't find a suitable egg?
Patches are welcome, unless I first rip out ez_setup.py altogether in a fit of pique. :)
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, 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.) Kevin
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.
participants (3)
-
John Machin -
Kevin Dangoor -
Phillip J. Eby