[Distutils] easy_install - some thoughts

[Paul Moore]

I just built a couple of eggs, for interest, experimentation, and
generally "having a go" with setuptools. A couple of things struck me
about the end-user experience with easy_install:

1. It would be much better if easy_install was usable via python -m,
   either as well as or instead of the existing easy_install.py
   script. On Windows, C:\Python24\Scripts is not normally on %PATH%,
   so easy_install isn't directly available after installing
   setuptools, without an additional step.

2. It would be useful if the -f option worked with a file: URL (or
   better still, a simple directory name), to handle local
   repositories.

3. I still dislike the fact that I can't get a listing of installed
   eggs. And uninstalling by deletion isn't good, IMHO. I am
   *strongly* averse to using raw file operations (delete) on files
   in Python\lib\site-packages. Elsewhere, fine, but I view the
   Python standard library as a "managed" area, and management tools
   should exist for it. That's the key benefit to me of bdist_wininst,
   and I don't see eggs providing it.

4. --dry-run doesn't work as expected:

>\Apps\Python24\Scripts\easy_install.py --dry-run dist/alarm-1.0-py2.4-win32.egg

Processing alarm-1.0-py2.4-win32.egg
Copying alarm-1.0-py2.4-win32.egg to C:\Apps\Python24\Lib\site-packages
Traceback (most recent call last):
  File "C:\Apps\Python24\Scripts\easy_install.py", line 18, in ?
    main(sys.argv[1:])
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 987, in main
    setup(script_args = ['-q','easy_install', '-v']+argv, **kw)
  File "C:\Apps\Python24\Lib\site-packages\setuptools\__init__.py", line 51, in
setup
    return distutils.core.setup(**attrs)
  File "C:\Apps\Python24\lib\distutils\core.py", line 149, in setup
    dist.run_commands()
  File "C:\Apps\Python24\Lib\site-packages\setuptools\dist.py", line 419, in run
_commands
    self.run_command(cmd)
  File "C:\Apps\Python24\lib\distutils\dist.py", line 966, in run_command
    cmd_obj.run()
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 222, in run
    self.easy_install(spec)
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 260, in easy_install
    return self.install_item(None, spec, tmpdir, True)
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 294, in install_item
    dists = self.install_eggs(download, tmpdir)
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 414, in install_eggs
    return [self.install_egg(dist_filename, tmpdir)]
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 491, in install_egg
    return self.egg_distribution(destination)
  File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py",
line 456, in egg_distribution
    metadata = EggMetadata(zipimport.zipimporter(egg_path))
zipimport.ZipImportError: not a Zip file

Don't get me wrong - eggs are definitely going in the right
direction. But there's still a way to go (for me, at least) yet.

Some more unfocused and rambling thoughts:

A nice to have feature would be the ability for easy_install to pick
apart a bdist_wininst installer and build an egg from it. This would
enormously help Windows users who don't have a compiler, but do want
to use eggs - in my view, it's fairly "all or nothing" choice. You
*don't* want to have part of your installation managed via
bdist_wininst installers (more accurately, by the OS native package
management), and another part by EasyInstall.

On a related note, had you thought of having EasyInstall put eggs in
a specific subdirectory? Something like site-packages/eggs? As you're
using .pth files, this wouldn't be any harder to manage, would it?

I can see a use case for a "combination" egg. One which packages
together a group of packages. For example, if I want a standard set
of packages installed on all machines, so that users can assume they
are present when writing one-off scripts. If I could package
*existing* eggs up into a combination site-std.egg (this is a pure
aggregation operation, and should not require the ability to build
extensions) then I could install the one egg across the site (and
version that independently of the individual packages). There's a
similar facility available in TCL's "starkits" (see
http://www.equi4.com/starkit.html) - which are well worth a look for
ideas, as they are fairly similar in concept to eggs.

Paul.
-- 
Once the game is over, the King and the pawn go back in the same box. --
Italian Proverb