matplotlib-devel Mailing List for matplotlib

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...@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.
>
> 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

> 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.
After thinking about the problem a little bit I have gone for the following 
solution. I added support for mathtex to use the wrappers provided by 
matplotlib for FT2Font and _png. It is likely we will want to keep them in 
sync anyway -- so that should not be an issue.
However, I am having trouble working around the fact that mathtex is two 
levels deep (lib/mathtex/mathtex). I can either get the setup.py file to 
install either just the setup* stuff from mathtex or install mathtex as 
mathtex/mathtex. Not sure how to work around this.
I have committed what I have thus far to the branch.
Regards, Freddie.

On 2009年07月29日 08:17, John Hunter wrote:
> 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.
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.
-- 
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

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

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.
Cheers,
Mike
Freddie Witherden wrote:
> Hi,
>
> I was thinking about the problem of including mathtex in matplotlib earlier 
> and came up with an alternative means of 'solving' the problem.
>
> Instead of hacking setup.py to install mathtex on the behalf of matplotlib it 
> may be easier to leave it up to the user/packager to install mathtex.
>
> While simplifying the code (not as many changed are need to the setup files) it 
> also eliminates the problems associated with one package installing another 
> package (matplotlib installing mathtex).
>
> This could be done either through ones distribution package manger, standalone 
> (getting the mathtex source) or just by following the instructions in 
> lib/mathtex/INSTALL. (Checking out matplotlib also checks out the mathtex 
> source into lib/mathtex.)
>
> However, I am interested if this solution is acceptable to the matplotlib 
> developers.
>
> It may also be worth pointing out that mathtex is an optional dependency of 
> matplotlib and is not required for matplotlib to function.
>
> Regards, Freddie.
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA