[Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements
Mark W. Alexander
mwa at gate.net
Tue Feb 27 16:55:03 CET 2001
On Tue, 27 Feb 2001, Doug Hellmann wrote:
> Date: Tue, 27 Feb 2001 10:17:06 -0500
> From: Doug Hellmann <doughellmann at home.com>
> To: python-list at python.org, distutils-sig at python.org, catalog-sig at python.org
> Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python
> - requirements
> > 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.
> 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
> > 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
> OR third party volunteers post binary distributions to other sites on the
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?
More information about the Python-list