CPAN functionality for python - requirements

[Sean Reifschneider]

On Mon, Feb 26, 2001 at 10:45:38PM -0500, Doug Hellmann wrote:
>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.

Apaprently I wasn't canonical enough...  On an rpm-based system, it's
bogus if "rpm -qa" doesn't list packages installed by CPAN.  Just as it's
bogus for the similar to happen on Debian, HP, Sun, Windows, etc...

>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

That's one argument, and I'd say it's a good one at that...  Other reasons
are:

	The admin doesn't have to learn new packaging formats to deal with the
	Python packages.

	If we don't leverage off the platform's package management tool, we have
	to write our own.  Who's volunteering?

	If the packages aren't listed in the native packaging system, they are
	much more likely to get overlooked if admins search for things to
	update and the like.

>1. Locate Python packages you want on the net.

By "packages" do you mean modules only?  I envision it also handling
distribution of Python applications and even Python itself.

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

Yes.

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

That seems to be where we diverge...  If somone has made an RPM of it, I'd
rather have that than some files winding up hanging around my file-system.

>3. Need to include documentation along with source for packages.

Not gonna happen...  Until there's tools and standards for such documentation,
it's not really possible to deal with them...  In the cases where docstrings
are used, installing the module produces the documentation, but that seems
to be the exception...

>complexity of the new tool.  (How do we handle RPMs on MacOS?  How do we handle

My schema lists the package format, architecture and platform.  If you
search for a package for MacOS, and are returned an RPM, then apparently
somone has built an RPM for MacOS.  Your client should list the package
formats that it desires and prefers, which means that if you don't have
RPM on your Mac, you will pull down something else -- without penalizing
those who *DO* have RPM running on their Mac...

>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

My setup handles that -- set the platform to "pilot" and you get access to
only the things that will work there (in theory).

Again, there are two distinct things here.  The archive network and the
tools which make use of it...

>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 say "we force the user to specify".  I say "we allow the user the choose".

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

CPAN is a Unix-like directory structure, files are downloaded as .tar bundles
which are extracted and a "perl Makefile.pl; make; make test; make install"
is run.  Does Pippy have "make"?

Sean
-- 
 Gone Postal Sort: Iterate over elements, any element that is out of order you
 blow away.  -- Evelyn, Kevin, and Sean, watching Monty Python and reading DDJ
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python