[Distutils] Re: CPAN functionality for python - requirements

[Mark W. Alexander]

I have no idea how this cc: list came to be. I'm adding catalog-sig
and will drop individuals on subsequent posts....

On Tue, 27 Feb 2001, Bruce Sass wrote:
> Subject: [Distutils] Re: CPAN functionality for python - requirements
>
> > 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.

It seems there's a misunderstanding of what distutils does. It provides
a standard mechanism for producing installable python packages. IOW,
exactly what's under discussion here. It does so by the package
author providing code and meta-data. Distutils uses the code to
produce the python/C modules, and the meta-data to produce binary
packages in _any_supported_format. Currently, RPM, tar.gz, and 
Windows installers are included. Solaris and HP-UX package support
is available in horrendously hacked format, but it's been demonstrated
to be possible. I imagine dpkg to be of minimal difficulty for 
someone who understands debian packaging. Note that, theoretically
at least, the author needs no knowledge of packaging for distutils
to do it's work. All they need to know is what meta-data is
required by distutils. (I think there are still some issues regarding
a "standard" meta-data base that is necessary to support "all" packagers,
but that's not in insurmountable problem.)

So distutils can be used to do the installation. The problem,
however, is in the capabilities of the target system. Is there
a compiler available for compiled modules? If not, the source
is worthless, and the user is forced to rely on binary packages
(a significant number of Windows users, I'd imagine), driving a
requirement that the network provide (at least some) binary
packages in directly downloadable form.

OTOH, if compile time requirements are met (compiler, linker, SWIG,
whatever else the author uses), then distutils can easily produce
a binary package on the target machine, as long as the target's native
package manager is supported by distutils. And as long as all
dependency requirements are met.

So the catalog client will need to be able to acquire dependency
information from the network archive in order to ascertain whether
the module is buildable on the target system. If it is, it will
also need to acquire, invoke distutils to build and package, and
invoke the package manager to install all dependencies in order.

If it is not buildable, then it would need to seek out pre-built
binaries, download and install them. So, either the network archive 
interfaces with distutils such that a back-end can produce binaries,
OR archive maintainers manually produce binaries for whatever
platforms they choose to support, OR people without development
tools (Windows, Macs(?), disk-space tight OS's) are SOL.

I hope this clarifies distutils (potential) role a bit.

mwa