r12 - 13 Jul 2007 - 15:39:36 - MikeTYou are here: OSAF >  Developers Web  >  DevelopmentHome > ChandlerInstallers

Chandler Installers


Currently we have an installer for Windows, a .dmg distribution for OS X and a RPM for Linux.


  • Installers should work like the majority of installers on any given platform:
    • Executable on Windows -- WindowsInstaller
    • RPM on Linux (other package systems may also be supported) -- LinuxInstaller?
    • Drag and Drop on Mac? -- MacInstaller
  • distutils may be used to install Python packages
    • MikeT should the installation script ask if any new packages are to be installed into the system site-package or into a chandler specific location? Right now the whole issue of upgrades (by either Chandler or the user) is being side-stepped since Chandler includes everything but if we are using the user's existing packages then there exists the chance that an upgrade will break Chandler.
    • HeikkiToivonen - Not sure yet.
  • Chandler should use system Python where possible
    • MikeT since installer disk footprint is a concern, it may be necessary to have two versions for windows - one that contains a python installation and one that does not. I use windows in this example as it is the only platform that typically does not have python installed. This also may be a concern because of the python 2.3+ version requirement.
    • HeikkiToivonen - There should be only one installer for each platform, because we can't expect the users to make any decisions like that. The installer would ideally contain no Python, but would download and install as needed. I.e., I prefer a "net installer", but for the first version we can go with a fully bundled version as well because net installers are harder to do.
  • Installers should be minimal in size
    • Use components already installed on system when possible
      • MikeT the only components I have run across so far that I would hesitate to use is dbxml, xerces and pathan. Because the repository is tied so tightly to these components and they exist as dynamic libraries, it may be a whole lot easier to always have them in a Chandler library location.
      • HeikkiToivonen - If we specify the versions we require, how would it matter?
      • MikeT my thought on this was that the repository is tied to specific (and patched) versions so if a user upgraded any of the components it could possible make Chandler stop working. Keeping a select few of these private would remove that risk.
    • Download and install missing components
      • MikeT download from osaf or from vendor sites?
      • HeikkiToivonen - If licenses permit, I would be in favor of OSAF site because that way if the users can download the installer they should also be able to download the packages. If packages are to be downloaded from vendor sites, their site might be down, or they might change the download locations.
  • The installers should work on all of our supported platforms: Windows XP, Mac OS X (10.3 and newer), Ubuntu Linux.
  • The installer should install the .py files, and compile them to .pyc and .pyo
  • The installer may create _ _ repository _ _ (but see dependencies)
  • Creation of the installer must be possible to do in an automated fashion, for example by Tinderbox clients
  • Tests, ideally automated somehow

  • Need installation/usage requirements docs (disk space at least, we can think about memory and processor etc. later)
  • Need developer docs and end user docs


Projects.PageType DevDocPage
Projects.MaintainedBy other
Projects.PageStatus Work in progress -- this page is still being drafted?
Trash.CommentsWelcome2 Feel free to contribute comments?
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r12 < r11 < r10 < r9 < r8 | More topic actions
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.