On Wed, Jul 29, 2009 at 5:05 PM, Robert Kern<rob...@gm...> wrote: > Furthermore, you could put numpy in there, too. Maybe even recipes for > downloading and building the C dependencies for those who need it. Basically, by > freeing yourself from the shackles of distutils, you can make the > "new-to-Python-just-give-me-matplotlib" experience much less painful while > improving the situation for downstream packagers like Linux distributions, EPD, > and python(x,y) at the same time. For linux, unix and os x src installs, this is imminently viable. We already have a start on this in the mpl/releases dir to autofetch the deps and build them, but this is for the lower level deps, like freetype, png and zlib. We could easily extend the approach to pytz and dateutil, and provide some enhancements (remove make, use python instead, have some sort of configure file support). The bugaboo is the win32 installer and OSX binary. If we don't build this stuff in, suddenly the dependency list grows from "just install numpy" to "install pytz, dateutil, numpy and mathtext" which is a very different picture. As I alluded to in my earlier post, I assume there is some way to build smart windows installers (eg along the lines of the ETS install tool or native win32 solutions) but this is a question of manpower. None of our core developers are primarily win32 users, and we often struggle to get anyone to even test a win32 release candidate, much less do the heavy lifting to build a smart installer. The ETS and PythonXY solutions have gotten so good that maybe I should just give up worrying making life easy for win32 users, since these solutions already satisfy the needs of someone who wants it to work with one or two clicks. I already aggressively point them to these solutions on our installing page. But windows users still make up about half of our known installations, so I don't want to be cavalier in dismissing the importance of making it easy for them.