ActivePython 2.6 Installation Path Caveat

March 10th, 2010 by Python Simple Leave a reply »

pathIn a prior reading we recommended to install Python on Windows into C:\Program Files\Python\X.Y (with X.Y being the Python version number). Alas, due to a bug in one of the included ActiveState’s tools, there is a minor issue with this installation location. Fortunately, there is also a very simple workaround.

The Problem

The ActivePython 2.6 distribution includes ActiveState’s new Python Package Manager, PyPM. PyPM is relatively young, it’s labeled “beta”, and – not surprisingly – is the source of mentioned issues: It contains a bug that effectively prevents running PyPM from a path that contains a space.1

The problem can be tracked down to a simple application invocation bug: On Windows, to execute a program path that contains a space, the program path must be enclosed in quotes. Hence

"C:\Program Files\Foo\Bar.exe"

will work, but

C:\Program Files\Foo\Bar.exe

will try to execute C:\Program instead (with “Files\Foo\Bar.exe” as argument) and fail.2

Note that this is only an issue with Windows in languages where “Program Files” actually contains a space. For example, the German version of Windows XP uses C:\Programme as default program directory, so the issue doesn’t manifest.

Problem Analysis

We investigated the problem further and discovered that it is not directly related to the path where Python is installed, but to the path how Python is invoked. (The two are usually, but not necessarily the same; see the solution.)

When ActivePython is installed, it adds the installation path to the program search path (the PATH environment variable), so you can execute “python” from the command line from every directory. Even when you execute a script (like pypm) on the command line, python.exe is searched on the PATH, and it is invoked from there. The python invocation path is stored in sys.executable, from where it is obviously used by PyPM – in a wrong way.

The Solution

The simple solution that worked for us was to change the python invocation path without reinstalling it. Our solution is rather generic, it fixes the whole family of issues connected to “Program Files” containing a space, not just the PyPM issue that gave rise to it.

This is how to do it:

Step 1: Create a symbolic link to C:\Program Files that does not contain a space, call it Programs. On Vista, this can be done using the command line:

mklink /j C:\Programs "C:\Program Files"

On Windows XP, you can use the junction utility to create symbolic links to directories:

junction C:\Programs "C:\Program Files"

Step 2: Replace the PATH entry C:\Program Files\Python\X.Y with C:\Programs\Python\X.Y. (Here’s how.) For first-time python installs, you can install it into C:\Programs\Python\X.Y right away.

This way, the standard program location is preserved and the blanks-in-paths issue is resolved.

Update: The author of PyPM, Sridhar Ratakumar, has kindly provided an alternative and easy to apply fix for the concrete PyPM issue. See his comment below. Keep in mind though that, of course, it does not help when other programs do not handle spaces in paths correctly (happens more often than one might expect).


We still advise to stick with the recommended installation locations. For one, PyPM will mature, and “child diseases” like the one described here will go away. Meanwhile, the shown directory link hack will do the trick.

To prevent future issues with Program Files you may want to install all your programs using the newly created link.

  1. This is a type of bug that should be a matter of the past given how long paths with spaces exist, but… []
  2. We have never understood why Microsoft has chosen a two-word name, “Program Files”, for their default program location, when “Programs” would have prevented so many of the early – and obviously still occsionally recurring – problems with spaces in paths. []

1 comment

  1. srid says:


    I am the developer of PyPM. And we do have a bug open for this. You could also try the workaround mentioned in the bug:

    This will obviously be fixed in the next release of ActivePython (2.6.5.x).

    Thanks for the analysis and providing a solution in your blog!

Leave a Reply

Please ignore these 2 fields: