Hi all --
[oops: I *said* that I was cc'ing this to python-dev when I posted it to distutils-sig, but I just plain forgot to. So here it is again, still presumed relevant to python-dev'ers because it directly affects the planned Python 1.6 feature set. Please reply either to me directly or to distutils-sig, because that's where the implementation will be done.]
recent developments in the planned release schedule for Python 1.6 (Guido doesn't want to wait for everything planned, but get something out the door in the next couple of months) are lighting a fire under me to get a seriously usable version of Distutils ready *really* soon now. This will be Distutils 0.2; I anticipate that 0.2.x will be included in Python 1.6, where x is the number of attempts it takes me to get something reasonably bug-free out the door.
Those if you who were at the Python Conference this past week will have seen bits and pieces of my "laundry list" of desired features that should be added to the Distutils at some point in the future. Given the shortened schedule, it looks like it's necessary to do some pruning and concentrate on the essentials to get something in Python 1.6.
So, here is my current laundry list, sorted into a couple of categories:
essential for 0.2 (Python 1.6) ----------------- * fix the "dist" command (two-phase manifest, better feedback) (steal ideas and hopefully code from Gordon Macmillan's installer) * fix the "install" command (have the right interface and do the right thing for installating to non-standard or personal directories) * fix some bad nomenclature in the command classes (most likely 'options' -> 'user_options', 'set_default_options()' -> 'initialize_options()', and 'set_final_options()' -> ??? (maybe 'finalize_options()'?)) * build C libraries (for PIL, and other similar distributions) * documentation (two small manuals that should become standard Python manuals: "Installing Python Modules" and "Developing and Distributing Python Modules") * add a bdist command; should at least be able to generate dumb archives of built distributions (eg. a tarball that you unpack from /usr/local, or maybe /usr/local/lib/python1.5/site-packages)
desirable for 0.2 ----------------- * "what's installed" database * dependency checking ("is version 1.3 of foo installed?") * don't automatically clobber an existing installation -- confirm, or require a "force" option, or something * command to install C headers (assuming more extensions than NumPy need to do this)
put off to 0.3 (Python 1.7?) ---------------------------- * JPython support (most importantly, know where to install .py modules when run from JPython and be able to build Java extensions for JPython) * build static Python binary (for shared-library-challenged OSs) * SWIG support (mainly, know how to run it before building the C extension it generates) * PyFort support (ditto) * Mac support * allow overlapping multi-architecture installations (Michel Sanner's pet peeve and Guido's nightmare ;-) (this would *not* be the default; it would have to be explicitly chosen by brave/cheap/foolhardy installers) * support for archive sites (Parnassus) to pull out meta-info
Anyone feel strongly about moving any of these items around, or discarding any entirely, or adding anything? Please let me know by email; I'll summarize to the list.
"GW" == Greg Ward firstname.lastname@example.org writes:
GW> desirable for 0.2 GW> ----------------- GW> * "what's installed" database GW> * dependency checking ("is version 1.3 of foo installed?")
These are *not* desirable for version 0.2. Paul Dubois expressed some concern about the complexity of these tasks. I agree completely. I think the chances of getting this done correctly in the next month are slim to none. Don't waste your time adding the kitchen sink to distutils :-); just bang on the simple stuff until it's rock solid.