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