[Catalog-sig] Initial requirements

[Robin Dunn]

>
> What if the user installs packages w/o using any of the tools, by
> downloading it and running "python setup.py install"?

Then you slap the user's hand and tell 'em not to do that!  <wink>

> You'd really
> need a Python-wide database of installed packages; at the very least
> this is a question for the Distutils.

I agree distutils should update the DB when packages are installed, but
should it be the master of it?  If so then I would think that it should also
be the one that checks dependencies, fetches dependent packages, etc., which
I think is overloading distutils responsibilities too much, and maybe limits
the ability of other tools from interacting with the data and also being a
package manager.

Also, the current entry point into distutils is a package's setup.py file
which wouldn't make much sense for a generic package manager.  So there is
going to have to be a separate utility to front-end distutils anyway so why
not keep it all separate so that we can end up with different ones for
different needs.  For example, a command-line version**, a tkinter version,
a wx version, one integrated with IDLE, Boa, PythonWin, or PythonWorks,
etc...

Here is what I was thinking of when I spent a few brain cycles on this a
couple weeks ago:

1. There should be a module (or package)** that is part of the standard
distribution that manages access to a local DB (could be as simple as a
shelve of pickled objects, or maybe an XML file) that contains the meta-data
about the installed packages.  The module should handle reading the DB into
a collection of objects that can be read by the various package manager
tools, adding new meta-data objects to the DB, deleting ones that have been
uninstalled, locking the DB file, etc.

2. The distutils install command should (by default) use that module to
update the DB with the installed package's info, refuse to install if there
are dependencies missing, etc.  There should be flags to disable both of
these in case the package tools want to update the DB themselves or
whatever.

3. The various package tools also use the module to access/update the DB,
but go the next step and know how to fetch the list of archive mirrors,
fetch the master package list from an archive, fetch a package and
dependencies from an archive, install and uninstall packages, etc.  Much of
this could be factored out into the standard library module/package to go
along with the DB access, but it should all be designed to be extended by
the package tool so they have the freedom to customize behaviour (especially
the IDE integrations) and add whiz-bangs where appropriate.

4. While I agree that everybody should move to using distutils the simple
fact is that it's either going to take a long time to get there, or that not
everybody will do it.  For this I think it would be nice to allow the
package tools and the archives to deal with non-distutils based packages,
perhaps simply by adding to the meta-data the name of a python file in the
distribution to execute to do the install.  This could default to "setup.py
install" or something...

5. The package meta-data should also include information about pre-built
binary distributions for various platforms.  The package tools can then
fetch the proper binary if available and install it (either un[g]zip it in
the right place, or execute an .exe, run rpm or whatever)


** As long as they are not tightly integrated with distutils perhaps the
command-line package tool and the library module could be distributed as
part of distutils for convenience.


Disclaimer:  All this is just my rambling thoughts on the subject and I've
already changed my opinions a couple times since starting to write it... ;-)
There will probably be a better solution that everybody likes better, but
maybe some of these ideas will help out too.

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxPython.org     Java give you jitters?
http://wxPROs.com        Relax with wxPython!