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]. [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$