It's pretty easy to build an installer for Python these days (2.6 onwards). Yesterday, I built three, one for each version of Python I released for Stackless Python (2.6.3, 3.1 and 3.1.1).
After retrieving the source code for the version of Python you want to build an installer for, you also want to retrieve and compile the source code for all the dependencies (bzip2, sqlite, tcl..). This is almost completely automated for you by the scripts used for the Python buildbots, although you'll want to be using a Visual Studio command prompt so that the compiler is available to the script.
cd release26-maintAfter executing this script, the dependency source code has been downloaded and built to some extent. You still need to read external.bat and reexecute the TCL and TK compilation commands with DEBUG=1 removed.
Given that you are of course using Windows, you need to do some manual compilation.
cd Tools\msiAnd also build the documentation, to produce the extremely helpful CHM file. The first command retrieves the source code for the documentation generating dependencies, the second builds the CHM file. The documentation build scripts work with versions of Python earlier than 3.0, so you need to make sure that the scripts know where to find a suitable version.
nmake -f msisupport.mak
nmake -f icons.mak
cd DocNext the release build needs to be done in Visual Studio. This actually needs to be done twice, as there are failures (most likely due to dependencies in the build process) in the first attempt.
And with everything now prepared, the installer can be built. As with the documentation, the version of Python used needs to be pre-3.0 and it needs to have the pywin32 extension installed.
cd Tools\msiIf this errors complaining cabarc.exe cannot be found, then execute the SetEnv.cmd script provided by the Microsoft Platform SDK you have installed before rerunning msi.py.
And that's it. At this stage, you'll have a Python installer of your very own, perhaps even with a customised standard library. You can edit some variables at the top of msi.py if you want the built installer to be customised to some extent.
One thing to keep in mind is that this build process is the one used to create standard Python installers. Any installer built using this process for a given version of Python (2.6, 3.1, ...) will be considered identical to any other installer built for that version of Python. Have the official Python 2.6 installed? Then to install Stackless Python 2.6 or your own custom version of 2.6, you will need to uninstall the existing version of 2.6 before you an install a different one. Rather than just being a legacy of the installer build process, this actually serves a purpose. Python installs its DLL in Windows' System32 directory, for 2.6, it will be named python26.dll. It just isn't practical to change the DLL name for a custom Python installation, so the custom installers being identified as the same for Windows' purposes is actually beneficial.