DISTUTILS 1.0.4 PLANS
---------------------

* fix bdist_dumb

* get the test suites running again

* document the recent bdist_wininst improvements (Thomas Heller)


DISTUTILS 2.0 PLANS
-------------------

[MAL]
* binary packages should include the Python version in their
  filename

* all distutils packages should include a package release number
  (like the RPM one) meaning that you can generate new package
  versions without having to bump the software version number;
  we could use a new setup() keyword "release" for this  

  Filename format suggestion:
  packagename-pkgversion-binaryrevision-pythonversion[.platform].<ext>

[AMK]
* Konrad's suggested fixes (allowing single directories in MANIFEST, etc.)

* Additional install_ subcommands: for DTDs and SGML catalogs, for TeX files,
  any others that people suggest.

[Thomas Heller]
* extend the install_* commands so that they write uninstall
  information
 
* implement an uninstall command using the information above
 
* write a test suite for distutils (I've just read Martin Fowler's
  refactoring book, so I know that tests are needed for refactoring)

* refactor the build_ext methods, so that they are easier to
  extend (maybe this will also unify the CCompiler classes)
 
* fix the *_clib commands (bug #414032 on SF)
 
* implement test command: often requested (but low priority IMO)
 
* docs, docs, docs (Thomas Heller promises to completely document the
  windows installer, but nothing more)


GENERAL
-------

* think about how to support distribution-specific "configure" commands --
  eg. how can they push option values (include/library directories, that
  sort of thing) onto the "build_ext" command?
  [see also "AUTO-CONFIGURATION" section below, and the "config" command]

* need a good, general-purpose, portable-if-you-want-it, unportable-if-
  you-need-control, way for the builder/installer to specify compiler
  and linker flags (lots of people expect CFLAGS and LDFLAGS to work,
  so they probably should; but options to either command and/or
  build are the right way, so those should be preferred)

* install_data should install to $prefix by default, not $prefix/share
  (and should warn if developer doesn't supply any dir component:
  installing right to $prefix is almost always the wrong thing
  to do)
  [done 2000/06/24 GPW]

* what's up with bdist_wininst running the install command but not
  installing scripts or data files (or whatever)?  and why does the
  C side of the installer have to worry about extra_path and .pth
  files?  that should Just Work...

* config files should accept hyphen as well as underscore separators,
  and should accept "negative alias" options too


DOCS
----

* write write write


PATCH REVIEW/INTEGRATION
------------------------

* nothing at this point


COMMAND-LINE PARSING
--------------------

* drop fancy_getopt and replace it with optparse

* I think fancy_getopt needs to get fancier to properly support the
  -I, -D, -l, -L, etc. options of "build_ext": need to be able
  to accumulate multiple options in a list, should be able to
  split a string on a given delimiter, probably want to specify if
  repetitions of the same option will accumulate or replace, etc.

* do the above options even work at all?  seem to recall hearing
  reports of dismal failure, but I never looked into it
  [knowing how FancyGetopt works, there's no way these options
  can work: damn]


COMPILER MODEL & CLASSES
------------------------

* add pre-processor interface to CCompiler (needed to support
  Autoconf-style 'try_cpp', 'search_cpp', 'search_headers' in config
  commands)
  [done, but only UnixCCompiler implements that interface]

* fix UnixCCompiler so it doesn't depend on sysconfig (ie. cc must
  be passed in)
  [done 2000/06/24 GPW]

* allow user to supply cc (compiler executable) in addition to
  compiler type
  [done 2000/06/24 GPW]

* radically simplify CCompiler method signatures: drop most of the
  per-invocation customization, and just use the instance
  attributes for eg. include_dirs, libraries, ...
  [NB. should probably hold off integrating Cygwin and Borland
   support until this is done, *if* that is it is the right thing
   to do...]
  [update 2000/06/24: I'm cooling to this idea; it turns out the
   extra complex interface that's been there all along is useful
   for the "config" command, which has to do lots of little
   temporary compile and link steps]

* Unix: -g comes from Makefile, and is unaffected by --debug or lack
  thereof (I think --debug is ignored by UnixCCompiler)


AUTO-CONFIGURATION
------------------

* add more goodies to the standard "config" command, and finish
  hacking up the example mxDateTime setup script to take
  advantage of them
  [partly done: at least enough is there to auto-configure mxDateTime;
   need to work on PIL's auto-configuration next]

EXTENSION BUILDING
------------------

* extension building on AIX
  [update 2000/06/24: Rene Liebscher has a patch for this, which
   I have asked him to refine]

* support for SWIG -- should just have to specify the .i file and
  have Distutils take care of running SWIG and knowing what the
  output is (to be really clever: make sure SWIG's output is included
  in source distributions, so builders-from-source don't need to
  have SWIG installed)
  [update 2000/06/24: Thomas Heller and I have gone back and forth
   on this a couple times: sounds like Thomas has the right idea,
   I'll let him work on it]

* support for PyFort (lower priority than SWIG!)

* OSF/1 problem: ld command has "*" in it, which is appropriate when
  a shell is involved, but there isn't one here, so we need to
  strip the quotes (and, ideally, put them back on again when
  spawn() prints out the command run!)
  [fixed!]

* support for building a new, static Python binary


INSTALLATION
------------

* if Distutils installs the first third-party modules in an installation
  (and creates site-packages), then "install" needlessly warns about
  having installed to a location not on sys.path -- presumably because
  site-packages isn't in sys.path at startup, since it doesn't exist
  until we create it!  (I think this is only a problem with 1.5.2,
  since site-packages is now created when Python is installed -- check!)

* need a mechanism for specifying pre-install and post-install hooks,
  which will be run when installing from a smart built distribution
  (RPM, wininst, etc.); also, "install" needs to run these hooks
  *except* for "fake" installs done solely to create a built distribution

* bdist_dumb should grow a little intelligence: let packager choose whether
  to make archive relative to prefix or the root (prefix is essential
  for proper Windows support )

* should be able to turn off byte-compilation (and optimized version too)

* need to test --compile, --optimize!  (--optimize doesn't work, that's
  for sure)

* write INSTALL_SCHEMES with slashes and convert to native format at
  install time -- that way, we can use the "windows" install scheme
  on Unix to create wininst installers that include scripts, data,
  headers, etc.


DISTRIBUTION FORMATS
--------------------

* bdist_rpm ignores the Python you ran it with, and just puts
  "python setup.py ..." into the setup script

* make "bdist" take multiple formats (both for convenience
  and consistency with "sdist"); should be doable now that we can
  reinitialize, refinalize, and (presumably) rerun commands
  [done 2000/06/06 GPW]

* Wise installer for Windows ("bdist_wise")
  [Thomas Heller said he will work on this when "bdist_wininst" is done]

* should certainly put tarballs and zip files (sdist, bdist_dumb) in
  "dist" directory -- maybe RPMs, Windows installers too

* bug! bdist --format=gztar,zip doesn't work: premature cleanup

* warn if RPM version < 3.0.4


MISC
----

* sdist tends to blow up when making hardlinks in the distribution
  tree if a previous run blew up and left stuff already there


$Id$