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