[Distutils] packages and Maintaining Python in general

[Michel Sanner]

On Jan 19,  8:57am, Greg Ward wrote:
> Subject: Re: [Distutils] packages and Maintaining Python in general
> Quoth Sanner Michel, on 18 January 1999:
>
> > 1 - I started to use Makefile.pre.in to generate make file for
> > additional packages. Currently when any user types "python" he gets
> > 1.5 (current public version). So I decided to build Python1.5.2b1 and
> > install it somewhere not in the users path. The problem is that when I
> > use Makefile.pre.in it uses "python" and gets version 1.5. The only
> > work around I found was to edit the copy of Makefile.pre.in and make
> > it point to the 1.5.2b1 binary.
>
> This will definitely be addressed by the Distutils suite:
> Makefile.pre.in will be a thing of the past, replaced by a (usually)
> tiny Python script.  Normally this will just be run as "./setup.py", but
> of course you can always say "python1.5.2b1 setup.py" and the build
> process will follow the defaults associated with *that* particular
> binary (eg. compiler flags, installation directories, etc.).
>
Cool I see you guys already have a plan :). I guess I will have to browse the
archive of the mailing list to come up to speed ! Anyways is the plan to have
something available under 1.6 ? or maybe 1.5.2 (non beta ?)

> > 2 - When building Python for several architectures, the installation
> > script allows to separate platform-dependant and platform-independant
> > files.  I'd like the same for packages, i.e. when a package has both
> > types of files I'd like to be able to have a package with that name in
> > the platform-independant AND in the platform-dependant tree. This DOES
> > NOT work currently because import stops searching after it find a
> > package matching that name.
>
> I completely agree.  I think this will require some cooperation on the
> part of Python's configure/build process, and probably the startup code
> that initializes sys.path.  So it's only likely to happen when/if a)
> Distutils comes to pass as planned, b) Python 1.6 goes out.  But it's
> definitely an important thing to keep in mind.
>
Yeap, the main problem currently is that import stops searching after it find a
package with the right name. So you could NOT have an OpenGL package (for
instance) under $prefix and another OpenGL package under $exec_prefix. Is
someone talking to Guido about this. It seems to me that this separation
between acrh-dependant and arch-independant files should be allowed for
packages.


> > 3 - Numeric Python should really be part of the standard distribution
> > .. (please :). Actually I would even argue that it should be part of
> > the Kernel such that developers can rely on the fact that this data
> > type, CRUCIAL for any scientific application and key to Python's
> > success in that field is available.  This would also allow for
> > instance to have this datatype included in the Corba mappings for
> > Python.
>
> I disagree.  The whole point of the Distutils SIG is to make it trivial
> to add third-party modules to an existing Python installation; if NumPy
> being crucial for scientists justifies adding it to the core, then why
> not add PIL for image-processors, and so forth?  Where do you draw the
> line?
>
OK ! I think my level of frustration made me loose my objectivity :) ..
although
there is something special about Numeric: it implements a basic datatype:
ARRAYS that are as basic as lists or tuples. This I think makes a difference
with PIL for instance that might use Numeric Arrays to store images for
instance.
Moreover having this datatype be a part of Python itself would allow to define
CORBA mappings (which again I am personally interested in :)... Just pushing my
luck here :)

-Michel