[Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements

[Mark W. Alexander]

On Tue, 27 Feb 2001, Doug Hellmann wrote:

> Date: Tue, 27 Feb 2001 10:17:06 -0500
> From: Doug Hellmann <doughellmann@home.com>
> To: python-list@python.org, distutils-sig@python.org, catalog-sig@python.org
> Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python
>     - requirements
> 
[snip]
> > 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.

Agreed.

[snip]

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

Yes, after I sent this off, I started thinking this as well. It's
better as well for sites with multiple machines. Go get it once
and install everywhere.

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

That's an interesting question. What would it take to include
cross-compiling support in distutils?

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

That was my original thought. I would hate to see, however, that some
platform gets "slighted" because there's no one to run a mirror for
them.

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

These last 2 are where I hoped the combination of distutils and a
network archive would reduce the number of volunteers needed. 
As long as distutils can produce a binary for a particular platform/
package manager combination, there's really no need for a dedicated
(official or UNofficial) "package mantainer". All that's needed
is a place where "python setup.py --bdist format=MyPackager" works.
How about an interarchive-API (or redirector?), so archives can
forward requests for binary packages to other sites known to support
that type of binary package?

Mark