On 2009-07-29 15:29, Robert Kern wrote: > On 2009-07-29 08:17, John Hunter wrote: >> On Wed, Jul 29, 2009 at 7:52 AM, Michael Droettboom<md...@stsci.edu> 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. > > Instead of using the matplotlib package as a catch-all for these external > packages, could you instead keep them all nominally separate and release a > tarball that includes all of them side by side? You can even have an > installation script that will run the setups for each. Even better, this > installation script wouldn't use distutils, so you don't have to hack all of > this "optional package" stuff into it.
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. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
