At 08:45 PM 10/11/2005 +0100, Paul Moore wrote:
Integrate with platform-specific installers (in my specific case, bdist_wininst) so that the "list all packages" command (for example) lists *everything* installed, egg or not.
Feel free to implement that; I just don't offer an API that knows about arbitrarily installed things, since there isn't any reliable way (that I know of) to know that. :)
(This is the one that I view as a key requirement, and the one that I've never managed to get a decent start on - if I had, I might have delivered on my offer to produce some management scripts by now!)
My take on it is that if there are compelling reasons to use eggs (such as great package management tools), then sooner or later everyone will use eggs, and the legacy problem will take care of itself. EasyInstall also gives you the option to get rid of legacy packages when you install an egg of the same package.
And a couple of cases like that, where the egg conversion is imperfect, are enough to leave me thinking that life's too short, and go back to using the installer direct, and only even considering eggs when they are offered by the author, "officially".
Which is quite reasonable, and certainly doesn't make you any worse off than you already are. When enough packages use eggs, and more package management tools for eggs exist, this balance will shift. It's just going to take time. EasyInstall didn't even exist six months ago, and the pkg_resources runtime was still under construction.
PS I'm very interested in trying out TurboGears, which comes as an egg-enabled package, automatically grabbing its dependencies. But I'm scared to do so until I can set up a sandbox machine, as *all* of the machines I use regularly have at least one of TurboGears' dependencies installed as a non-egg, and I don't want the easy_install stuff to mess those up, nor do I want to uninstall my existing packages. Ironic that a system designed to make installations with dependencies *easier* has resulted in me being unable to "just try it out"...
If you're using a Unix machine, just use the "Non-Root Installation" procedure, or Ian Bicking's sandbox creation script, to set up a "virtual Python". Unfortunately, on Windows this is less than practical due to the lack of symlinks.
Later 0.6 releases of setuptools, however, are going to make it trivial to install packages to other directories than site-packages, while avoiding any conflict with already-installed packages. The target directory will have to be either a script/launch directory or else a PYTHONPATH directory, but other than that you'll have the full flexibility that you get when installing to site-packages now.
The issue right now is that pkg_resources always adds eggs to the *end* of sys.path, but future versions will add eggs in front of their parent directory on sys.path. There will also be a facility to create a dummy site.py to force Python to pay attention to easy-install.pth in the target directory, no matter what the target directory is.