[Distutils] setuptools in a cross-compilation packaging environment

[Paul Moore]

On 10/11/05, Phillip J. Eby <pje at 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"...