CPAN functionality for python - requirements

[Bruce Sass]

On Mon, 26 Feb 2001, Doug Hellmann wrote:

> On Mon, 26 Feb 2001, Sean Reifschneider wrote:
> > On Mon, Feb 26, 2001 at 06:45:33AM -0500, Doug Hellmann wrote:
<...>
> 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?

I want users to be able to find and install Python stuff, preferably
in a manner consistent with their native package management system.

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

There is no way an archive network can resolve dependencies because
ther is no way for the archive network to know what is installed on a
users machine (at least there had better not be!), or what packages
are available to fulfil those dependencies.  The best that can
be done is to tell the target system what is required by the pkg being
looked at.  The dependencies get resolved when the native system
decides on where it should fetch the other stuff from.

Dependencies are a big problem.  I've spoken with a local LUG member
who was complaining that Debian does not know about the stuff he gets from
CPAN, which makes mixing CPAN and debianized CPAN stuff a pain.
Debian's solution is a user level program to debianize arbitrary CPAN
modules... I want the same solution for Python modules, except I want
it done transparently.

> 3. Download the appropriate packages to give you what you want.
> 4. Install those packages.

Doesn't that mean the program needs to know about all the distros, and
all the version of those distros, and all the supported ways a user
can tweak the system.  If you don't do that, and keep it up, then your
installer is going to be breaking often (or always broken, depending
on the user or distro).

> Do we agree these are the primary features?

Both 2. and 4. are the domain of the target system.  2. can be
modified (or maybe just reworded).  4...

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

As long as distutils does not presume to know how to do the
installation.

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

Downloading is independent of the native package management system.
Complexity is only increased if the new tool thinks it should handle
platform/OS/distro specific issues.

> (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?

You don't.  You give the data to the target system and let it worry
about the complexity of packaging.

There is no reason for the archive network to know anything except
where to send the data!

> 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?

Pros:
don't know (long strings of punctuation and symbols give me a headache ;).

Cons:
Dependencies problems when mixed with modules fetched by other methods.


- Bruce