Differences between revisions 18 and 19
Revision 18 as of 2003-10-09 16:22:11
Size: 2895
Editor: n01p210
Comment:
Revision 19 as of 2003-10-09 16:58:55
Size: 3246
Editor: proxy12
Comment:
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
   (I agree with dependency specification, but suggest dependency resolution
   should be the responsibility of the repository/catlog and the binary package manager.)

 * Generation of multiple binary packages for a source distribution (ala Debian)
   (The Egenix tools is a good example of where this would be usefull)

  -- Mark Alexander

There are various fixes and improvements that should form part of a 2.0 version of Distutils.

  • Move various utility methods out of command implementations and onto the Distribution class.
  • Implement the package database described by PEP 262.
  • Consider always regenerating the MANIFEST from MANIFEST.in.
  • Finish bdist_dpkg.py
  • sdist: Include scripts, data automatically in the source distribution.
  • Drop Python 1.5.2 compatibility. Keep Python 2.0 compatiblity.
  • Improve test coverage.
  • Finish the documentation! (AnthonyBaxter has worked on a reference guide; his text is currently in [http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/distutilsref/ the CVS sandbox])

  • Package installation from PyPI (probably driven by the pythonmac-sig)
  • Add more autoconf-like tests to the config command
  • Make the design more extensible w.r.t. 'foreign' module compilation, specifically:
  • Allow the integration of autoconf/make based build systems for C/C++ extensions
  • Allow 'Extension' to be composed of components, each with their own build rules
  • Provide a means for scripts / modules to access installation parameters such as datafile directories
  • Define more default commands to build documentation, run (unit) tests, etc.

Wouldn't it be a good idea to look into [http://scons.sf.net scons] and try to let both converge as far as practical ? -- StefanSeefeld

Maybe some traditional package concepts:

  • Uninstallation. Also getting rid of obsolete files when upgrading.
  • Dependencies. A simple implementation might simply check to see if another library is installed and warn the user if not (and maybe install from PyPI if that feature exists). Declaring (or worse, resolving) version dependencies or alternatives seems like overkill for now.
    • -- IanBicking

      • (I agree with dependency specification, but suggest dependency resolution should be the responsibility of the repository/catlog and the binary package manager.)
  • Generation of multiple binary packages for a source distribution (ala Debian)
    • (The Egenix tools is a good example of where this would be usefull)
    • -- Mark Alexander
  • Easy installation of non-python data files that are stored inside Python packages. Twisted uses this for plugins, it's also useful for storing .glade files together with the code for GTK GUI apps, etc..
    • --
  • SciPy has some setup.py scripts that extended distutils. It may be a good idea to look there for ideas.

  • Allow MANIFEST and MANIFEST.in to be located in a directory other than the package root directory.
    • -- Michiel de Hoon
    • --
  • If you use a version management system that toggles the read/write bits (e.g. perforce), distutils happily copies the mode bits when it copies files down to the build directory (etc), and then chokes when it tries to clean up after itself. (or worse, skips important build steps so you end up with a broken release...)
  • It would be great if installers generated by bdist_wininst supported a 'silent' flag for automated installs. The silent mode would allow the package to be installed without user intervention.
    • -- Phil Rittenhouse

Distutils/Proposals/Distutils20 (last edited 2009-07-24 02:00:07 by FredDrake)

Unable to edit the page? See the FrontPage for instructions.