CPAN functionality for python - requirements

[Doug Hellmann]

On Mon, 26 Feb 2001, Sean Reifschneider wrote:
> 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.

Sure, all of that.  Anything which uses distutils for installation, right?

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

So why did distutils make it into the Python core?

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

Ok, so make that:

3. Need to support including documentation along with source for packages when
documentation is available.

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

But that leaves it up to the person posting the package to make distributions
in formats for any platforms where folks might want to install their stuff, or
to have someone *else* create those packages.  That may lead to a situation
where someone believes that they cannot install my package on MacOS because I
didn't make an HQX file (or whatever) when I posted HappyDoc.

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

Right.  We need to make it easy for the user to do the right thing.

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

I can go with "allow" but if we do not help then the user must specify in order
to get useful results from the tool, and that becomes "force."

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

So, it sounds like their tool just does the download and then they use the
equivalent of distutils to do the installation.  Is that all we want?

> is run.  Does Pippy have "make"?

I don't know about that.  Maybe it isn't even appropriate to support Pippy, I'm
not sure.

Doug