On 10/11/05, Phillip J. Eby firstname.lastname@example.org wrote:
At 04:56 PM 10/11/2005 +0100, Paul Moore wrote:
But for general packages (PIL, pywin32, cx_Oracle, whatever), I actively want a managed installation. I have made noises about building management tools for eggs, but I think I've been hitting the "absolutely requiring install/uninstall steps, which is anathema" philosophy, which makes such tools awkward to define.
Since I don't have a particularly rigid vision of what those tools will do, I'm wide open to suggestions and especially use cases for what you want to be able to do with them.
OK. The hard one first, and the one I think is most likely to clash with your ideas of what eggs are:
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. I see this as vital, as eggs are not going to replace bdist_wininst installers for a long time, if ever (get pywin32 and mod_python available as eggs, and I'll think again...) I need one, single, place where I can list all Python packages installed on my machine (and one command that does an uninstall, for that matter). Assume that a command prompt (or Windows explorer window) on a directory under C:\Python24 is disallowed - grubbing round in installation-managed directories manually is a definite no.
(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!)
By the way, although the support for wrapping bdist_wininst installers as eggs is good, it's not perfect. I know, for example, that the cx_Oracle documentation directory gets lost. Until that's corrected (I know, it won't be if I don't report it...) or the author supplies an official egg version, I'll continue to install cx_Oracle as a bdist_wininst 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".
I *know* these items probably don't match your priorities for eggs. We've had this discussion before. All I'm really trying to point out is that there's a fairly deep difference in our ideas. I'd stopped going on about it, as I don't have the time to provide code in support of my ideas, so I applied the "put up or shut up" principle :-) MAL's comments seemed to echo the same sentiments as me, so I thought I'd make one more post. I'll go back to lurking, now...
 MAL, if I've misinterpreted your comments, I apologise.
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"...