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.