[Distutils] setuptools in a cross-compilation packaging environment

[Phillip J. Eby]

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.