CPAN functionality for python - requirements

[Doug Hellmann]

On Mon, 26 Feb 2001, Sean Reifschneider wrote:
> On Mon, Feb 26, 2001 at 06:45:33AM -0500, Doug Hellmann wrote:
> >What if Python kept up with its own packages and modules like XEmacs does?  We
> >could then use the same format on all platforms -- it might even be something
> >we roll ourself to make sure we can unpack it with *only* Python installed on a
> >platform.
> 
> My understanding is that that's what distutils is meant to do, to an extent.
> The problem is that it's not entirely unreasonable to expect that an
> "rpm -qa" produce a list of all the software that's installed on your
> box.  If you don't use an RPM, you can't really make use of that, and
> packages WILL get dropped after a re-install.

The command "rpm -qa" only produces meaningful results on a system where RPM is
the default and primary package installation system.  There are more OSes where
that is *not* the case (and where RPM isn't installed at all) than where it is.

It still isn't clear to me why we would want to use more than one distribution
package format.  It appears that one argument is so that sysadmins can use
those tools to track what is installed on the system.  But isn't that part of
what this new thing (cyphon?) is supposed to do?  Do we want Python to require
an external package management system on each platform where this tool is
supported, or do we want a Python-esq tool which just works the way it is
supposed to, in the same way, everywhere Python is available?

But I think we're arguing over a design before we've worked out requirements. 
The basic tasks of this new tool, as I see them, are:

1. Locate Python packages you want on the net.
2. Resolve dependencies between what you want, what you have, and what you
   need.
3. Download the appropriate packages to give you what you want.
4. Install those packages.

Do we agree these are the primary features?

I sense a consensus that the "install" part should be handled by distutils.  Is
that right?  

Other requirements we might lay down up front:

1. Should run on all platforms where Python runs.
2. Must support mirrors on the server side.
3. Need to include documentation along with source for packages.

The features related to dependencies and downloads could be handled by a
platform-specific packaging system, but integrating with all of the different
options on all of the different platforms where Python runs increases the
complexity of the new tool.  (How do we handle RPMs on MacOS?  How do we handle
HQX files on Win32?  What about for Pippy, where files as such might not even
be appropriate?  Does Jython have any special requirements?)  Do we deal with
this complexity by deciding on a per-platform basis what format to use, or do
we force the user to specify the format they want downloaded?

If we're modeling what we're doing based on CPAN, maybe we should look at
that design.  What format does CPAN use when downloading Perl packages?  What
features does CPAN have that we want?  What does it not have that we want?

Doug