Project World Domination: Porting Sage to Windows

"I'll give Sage another try when I get a new computer (which hopefully isn't too far off), or when there is a native Sage for windows. Thank you for your time. For now, I will stick to straight Python. I admire your dedication to the Sage project and wish you success. I will give Sage another look later on." -- Travis; a typical potential Sage user.

The Sage project has been discussing the potential port of Sage to Windows via the MSVC toolchain for a long time. Since at least Sage Days 5 in Boston the discussion got a lot more serious and after securing funding from Microsoft Research we are finally on the way to do the port. The email that jump started the public discussion is listed below for posterity.

Team

Michael Abshoff (Dortmund) -- everything, i.e. technical lead, general design, porting components to MSVC, re-porting to Cygwin
Chris Gorecki (Seattle) -- porting pexpect to windows: http://sage.math.washington.edu/home/goreckc/sage/wexpect/wexpect.zip
William Stein (Seattle) -- management; porting components
Scot Terry (Seattle) -- Sage on Virtual PC

Intended Supported Platforms

32 bit: Cygwin
32 bit: MSVC 2005 or 2008 + Intel Fortran
64 bit: MSVC 2005 or 2008 + Intel Fortran

In the long term probably only 32 bit Cygwin and 64 bit MSVC + Intel are interesting, but 32-bit Windows will be around for a while, so it is important to support that, too.

Resources

Initial Email by William Stein to Michael Abshoff

Michael,

I want to somehow start a very tentative *actual* step toward doing a native 
windows port.   I installed Windows into vmware on my laptop yesterday.  I think
the first thing we need to do is decide whether we're going to:

   (1) build our own Python using mingw,
or (2) use the standard Visual C++ built Python that is distributed at python.org.

The advantage to (1) is .... I can't think of any, except maybe "control"
but my impression when we last talked was that you thought (1) was the way to go.
The advantage to (2) is that whatever we do it will play very nicely with
all existing Python libraries that get distributed for windows.  In particular,
graphics libraries, Enthought's Scipy for windows, etc., will all just work.
If we go the (2) route, we can just immediately check scipy/numpy off
the list, and any other python library that has been ported to native windows
already. If we do (2), step 1 will be to figure out the modern way to build
Python extensions against that standard Visual C++ built Python, either using 
mingw or Visual C++. I did this 3 years ago using mingw, and it was possible 
but painful.  Things may have changed.

Once we decide on (1) versus (2), the next step is to somehow get pexpect or 
some pexpect replacement (with equivalent functionality) to work in the
context of Windows. Once that is done, we can port the Sage notebook and all 
interfaces to Windows -- they're pure python and depend only on Twisted, so 
this shouldn't be impossible. We should also port the pure python matplotlib 
based plotting code, which should be easy. Next we port the calculus Python 
functionality, which is again pure python. Given a maxima binary, we'll then 
have Sage's calculus functionality and plotting fully ported.  This will on 
its own be a very useful program for a lot of people.

After that we can start thinking about the much harder parts of the Sage 
library that involve Cython, external C/C++ libraries, [lib]Singular, etc., etc.
By far the main difficult and thing that scares me above is pexpect. Even in 
Cygwin, pexpect sucked...

-- William Stein

Reading

Python Programming On Win32 -- looks very relevant