On Wed, Jul 29, 2009 at 7:52 AM, Michael Droettboom<md...@st...> wrote: > I think we need (at least as a transitional stopgap) a single "python > setup.py install" to install both matplotlib and mathtex. Once > distributions catch up (which could take more than a year, depending on > cycles), we can consider being more loosely coupled. > > There are already examples of installing subpackages from matplotlib > (pytz and dateutil) for example, and each of the extensions > (_backend_agg etc.) have examples in setupext.py showing how to > dynamically add extensions and packages to the list of things that > matplotlib's setup.py will install and build. Are there fundamental > differences in how that works vs. how mathtex needs to work that is a > stumbling block? I must admit I haven't thought it all the way through, > but I'm surprised that the existing examples there don't provide a > template for how to deal with mathtex. That said, I know that distutils > can be rather, um, labyrinthine. I second this. I would like to see the new mathtext (and png and freetype wrappers as necessary, possibly in mathtext) live in the matplotlib trunk under lib, the same place we put pytz and dateutil. It can have its own setup and release cycle, but I think it would make matters simpler to have it there. If there is compelling reason to have it live in a separate svn repo, we can always grab it externally, as scipy does for our sphinx extensions. We can use the mpl configure setup.cfg to either no-install/force-install/auto-install as we do for these other packages. This works fine at build time, but is a little more complicated when distributing binaries. Eg for win32 binaries, we currently force these packages on, which is sometimes a problem. We might be able to be a little smarter about building win32 installers, so the user can select which subpackages to install, but I am not holding my breath on this one. I am unwilling to rely on any setuptools solutions at this point, as I've always viewed them with suspicion (maybe because I rarely found easy_install to be easy) and the setuptools community is in a bit of disarray, with the lead developer unable to adequately maintain the package and unwilling to let those who want to take it over do so since he feels they are not qualified, so a fork is in progress: http://www.mail-archive.com/dis...@py.../msg08111.html JDH