[Distutils] Re: CPAN functionality for python - requirements

[Michel Sanner]

Hi,

I followed this discussion (probably not as much as I should have).
We have setup a Python distribution site for the tools we have produced for
computational biology. It is quite primitive but let's us distribute to "ready
to go" packages as well as pre-compiled Python interpreters for some platforms
to "non-wizard" users.

One issue that we are strugling with is versions of packages.Is there a
"standard" way to deal with versions ? how do you plan to find out whether
someone has a compatible version of any given package ?

-Michel

On Feb 26, 10:45pm, Doug Hellmann wrote:
> Subject: [Distutils] Re: CPAN functionality for python - requirements
> On Mon, 26 Feb 2001, Sean Reifschneider wrote:
> > On Mon, Feb 26, 2001 at 06:45:33AM -0500, Doug Hellmann wrote:
> > >What if Python kept up with its own packages and modules like XEmacs does?
 We
> > >could then use the same format on all platforms -- it might even be
something
> > >we roll ourself to make sure we can unpack it with *only* Python installed
on a
> > >platform.
> >
> > My understanding is that that's what distutils is meant to do, to an
extent.
> > The problem is that it's not entirely unreasonable to expect that an
> > "rpm -qa" produce a list of all the software that's installed on your
> > box.  If you don't use an RPM, you can't really make use of that, and
> > packages WILL get dropped after a re-install.
>
> 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.
>
> 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
> what this new thing (cyphon?) is supposed to do?  Do we want Python to
require
> an external package management system on each platform where this tool is
> supported, or do we want a Python-esq tool which just works the way it is
> supposed to, in the same way, everywhere Python is available?
>
> But I think we're arguing over a design before we've worked out requirements.
> The basic tasks of this new tool, as I see them, are:
>
> 1. Locate Python packages you want on the net.
> 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?
>
> I sense a consensus that the "install" part should be handled by distutils.
 Is
> that right?
>
> 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.  (How do we handle RPMs on MacOS?  How do we
handle
> 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
> 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?
>
> 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?
>
> Doug
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>-- End of excerpt from Doug Hellmann



-- 

-----------------------------------------------------------------------

>>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sanner@scripps.edu                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------