[Distutils] cleaning up packages

[Greg Ward]

On 05 June 2000, Randall Hopper said:
>      Some related distutils subtasks I also don't know about:
> 
>      1) Listing what packages are currently installed 
>         (pyncurses-0.3, Numeric-15.3, etc.)
> 
>      2) List what files in the python tree make up a package
> 
>         (/usr/local/python/PLATFORM/plat-irix646-n32/.../site-packages/my.so,
>         etc.)
> 
>      3) Delete the files for the specified package, and remove the package
>         from the installed list.
> 
> 
> Is this supported?  Slated for the future?

Punted on for now: the immediate concern is building, distributing, and
installing Python modules and applications, and -- even more important
-- generating "smart" installers that do all of the above work
(uninstall, list-what's-installed, etc.) for us.  Eg. if everyone in the
world used and RPM- or Debian-based Linux, we could just make RPMs or
Debian packages for people to install, and let those package managers
worry about these issues (not to mention dependencies, requirements,
conflicts, and all that other fun stuff).

I have no huge desire to reinvent the RPM wheel.  The guys at Red Hat
did a great job, and from what I've heard the Debian and Free BSD folks
have done a little better still.  However, the sad truth is that most
commercial Unices are saddled with abysmally awful package management
systems, and hardly any free software developers bother to support, eg.,
Sun's pkgtool (or whatever it's called).

Is it worth expending effort to support what is obviously a dying breed?
In the Unix world, Linux and *BSD are clearly the way of the future; all
of the commercial Unices save Solaris are gasping for breath, and -- as
any of my co-workers will tell you -- I would gladly stand in the firing
squad that ends Sun's time in the limelight.  (Hmmm, I hope statements
like this don't get me tagged as "another free software gun nut".  I'm
not, really!  I'm actually a raving anti-capitalist nut... ;-)

It's certainly an interesting problem, and it wouldn't be too hard to do
a 75% solution in Python, namely handle your wishlist.  (Handling
dependencies smells like a whole other kettle of fish.)

Be aware, though, that there has been one crack at this already: Michael
Muller submitted a patch back in January which I finally looked over in
April, but did not integrate into the Distutils CVS.  Anyone interested
in this problem should go dig up all versions of Michael's patch (I
think there were three of them posted) from the archive, as well as the
ensuing discussions.  As I recall, the first two versions wrote the
meta-data as Python code to be parsed; there was some objection to that,
so Michael invented a little format and wrote a parser for it.  That
still strikes me as the right way to do it, but for something about
Michael's implementation put me off, and I haven't looked at it since
April.

I think what worries me is the potential for profileration of
mini-languages for Distutils data.  There are already two: the
MANIFEST.in file and the config files.  MANIFEST.in will probably remain
a special (very simple) case, but I would like to see some unification
between the config files (data read by the Distutils) and generated
meta-data files (written by the Distutils, but would also be read by the
generic uninstall script, which would probably start "from
distutils.configparser import ...").

Requirements for such a generic format (and the interface that
implements it):

  * basic syntax close to ConfigParser's, but without the baggage
    of "%(name)s" substitution -- there's already a "$name" substitution
    mechanism in the Distutils, it just needs to be more widely used
    to allow substitution of configuration variables at logical points

  * better support for ConfigParser of multi-line data, specifically
    stripping leading whitespace on continuation lines should work

  * support for structured data: eg. "foo, bar, baz" for a sequence,
    "foo: 37, bar: 12" for a mapping (both of these should optionally
    allow shlex-style quoting)

  * maybe: support for typed data (eg. distinguish between string, int,
    and boolean values)

  * compatibility, possibly unification, with the FancyGetopt class --
    ie. setting command options from both the command line and
    config files should be no clunkier, and preferably less so,
    than it currently is

  * ability to track down where option value originated, ie.
    filename and line number

  * lightweight!  I don't want to see an Option class, where every
    command option is now a full-blown object instead of just
    a string or a list as it should be

Proposals are welcome!

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
I once decorated my apartment entirely in ten foot salad forks!!