[Distutils] Re: CPAN functionality for python - requirements

[Doug Hellmann]

On Tue, 27 Feb 2001, Mark W. Alexander wrote:
> I have no idea how this cc: list came to be. I'm adding catalog-sig
> and will drop individuals on subsequent posts....

I've done that, too.  It was getting a bit long.

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

I think the misunderstanding was on my part, and between your description and
reviewing the distutils help I think I'm straightened out now.

With that said, I agree that the network needs to allow, optionally, for binary
distributions for platforms where building binary distributions is unusually
difficult (like having no compiler on Win32).  All packages should be available
in source form (assuming some OS license) by default.  The client should offer
the user the option of downloading any available package format, which can then
be installed using a separate tool ("./setup.py install" or rpm or whatever).

If as a user, I choose to download an RPM, that's up to me.  If no RPM is
available, the thing I do download should be able to *make* an RPM, so that's
where distutils comes in.

So, we don't quite get to a *standard* set of download and install
instructions because downloading different package types requires different
installation steps.  By trading that off we get package management using the
user's favorite package system.  That seems to be a reasonable trade.

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

I'm going to back off my request that this be an all-the-way tool.  Let's stick
to finding a package and all of its dependencies, and leave the installation to
the packages which are downloaded.  As a Python user, I may not have system
privileges sufficient to allow me to install a downloaded package.  As a system
administrator, I may not know how to use this tool to find packages.  So, the
Python user can find the package and provide it to the sysadmin for
installation.  Nice and clean.  

Optionally, there could be an argument which would invoke an installation
command for the package(s) being downloaded.

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

Can I build binaries for all platforms on whatever platform I use for the
network archive?

> OR archive maintainers manually produce binaries for whatever
> platforms they choose to support, 

OR automatically.  If the source distribution is always available, part of the
mirroring process could be to convert the source distributions into binary
distributions for the platform serviced by the mirror site.

> OR people without development tools (Windows, Macs(?), disk-space tight
> OS's) are SOL.

OR developers who do not have access to platforms where binary distributions
are prefered enlist other interested parties to assist them in preparing binary
packages.

OR third party volunteers post binary distributions to other sites on the
network

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

Significantly.

Thanks,
Doug