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',
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.