Re: [Distutils] setuptools in a cross-compilation packaging environment
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.
I don't think that's really the case, it's just that implementing management tools is lower on my to-do list; I don't see them coming in until 0.7 or 0.8, and at the moment I don't have a strong vision of what those commands will look like, except that they'll be things like 'nest rm', 'nest ls', etc. (abbreviated forms) or 'nest uninstall', 'nest list', etc. (unabbreviated). 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. In the meantime, some of the things that are on my list ahead of the "nest" command subsystem are: * Making it possible for wrapper scripts on Windows to not conflict with a same-named module they import * --no-deps option for easy_install * changing the activation mechanism so eggs get added with higher precedence on sys.path than their containing directory, and that package name conflicts are checked at runtime * Automatic support for creating new "site" directories that allow .pth files, so that Unix users can install eggs anywhere without needing to have root access or create a virtual Python installation. Also, the --allow-hosts option, and maybe even signature checking, may end up landing before the nest command. Meanwhile, there's plenty of room for someone else to create management tools using the existing API, as most everything I've got on my list will not be changing the API or file formats or anything like that.
On 10/11/05, Phillip J. Eby <pje@telecommunity.com> 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[1], so I thought I'd make one more post. I'll go back to lurking, now... Paul. [1] 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"...
participants (2)
-
Paul Moore -
Phillip J. Eby