Stackless Python merge backlog

Over the weekend, I merged and released 2.6.3 and 3.1.1. In addition, I built an installer for 3.1 and also released that. I'm not entirely happy to see that it looks like the 2.6.3 release was rushed and there is talk of releasing 2.6.4 to make up for it.

In any case, I also made a list of the outstanding merges and releases that need to be done.

• 2.4.5
• 2.4.6
• 2.5.3
• 2.5.4

Hopefully I will find the time to get these done sometime soon, but they'll take a back seat to releases of higher versions, including the fixer-upper release of 2.6.4 should it happen.

Building a Windows Python installer

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-maint
Tools\buildbot\external.bat

After 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\msi
nmake -f msisupport.mak
cd ..\..\PC
nmake -f icons.mak

And 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.

cd Doc
set PYTHON=c:\python26\python.exe
make checkout
make htmlhelp

Next 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\msi
c:\python26\python.exe msi.py

If 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.