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.
Thanks --
Greg
[.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.
Thanks --
Greg