[Distutils] setuptools in a cross-compilation packaging environment

[Phillip J. Eby]

At 08:45 PM 10/11/2005 +0100, Paul Moore wrote:
>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.

Feel free to implement that; I just don't offer an API that knows about 
arbitrarily installed things, since there isn't any reliable way (that I 
know of) to know that.  :)


>(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!)

My take on it is that if there are compelling reasons to use eggs (such as 
great package management tools), then sooner or later everyone will use 
eggs, and the legacy problem will take care of itself.  EasyInstall also 
gives you the option to get rid of legacy packages when you install an egg 
of the same 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".

Which is quite reasonable, and certainly doesn't make you any worse off 
than you already are.  When enough packages use eggs, and more package 
management tools for eggs exist, this balance will shift.  It's just going 
to take time.  EasyInstall didn't even exist six months ago, and the 
pkg_resources runtime was still under construction.


>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"...

If you're using a Unix machine, just use the "Non-Root Installation" 
procedure, or Ian Bicking's sandbox creation script, to set up a "virtual 
Python".  Unfortunately, on Windows this is less than practical due to the 
lack of symlinks.

Later 0.6 releases of setuptools, however, are going to make it trivial to 
install packages to other directories than site-packages, while avoiding 
any conflict with already-installed packages.  The target directory will 
have to be either a script/launch directory or else a PYTHONPATH directory, 
but other than that you'll have the full flexibility that you get when 
installing to site-packages now.

The issue right now is that pkg_resources always adds eggs to the *end* of 
sys.path, but future versions will add eggs in front of their parent 
directory on sys.path.  There will also be a facility to create a dummy 
site.py to force Python to pay attention to easy-install.pth in the target 
directory, no matter what the target directory is.