matplotlib-devel Mailing List for matplotlib

Hi all,
I thought I had sent this code on Sunday, but apparently it didn't make it to 
the list. Apologies if it arrives twice.
This code was contributed by Rob Knight, from the biochemistry dept. at CU 
Boulder, to draw nice arrows with a lot of control.
You can see an example here (just paste the example data):
http://bayes.colorado.edu/cgi-bin/arrows/arrow_cgi.py
Both a CGI and a command line demo are attached, as well as the underlying 
arrow-drawing code. It would be great if this could be integrated into mpl 
for the future.
Cheers,
f

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> Also, I would like to drop support for the tex engine, and
 Darren> focus on latex only. These font issues we are addressing
 Darren> are beyond my ability (and interest) to support with tex,
 Darren> but they can be handled using the available font packages
 Darren> with latex. Objections?
I can live with it. Everyone I have ever met uses latex and not tex,
so I don't see too many objections...
JDH

Darren Dale wrote:
> Thanks Fernando. No, I do NOT want anyone to have to visit CTAN to make this 
> work. I added this when I was considering scaling the fonts in latex. Since I 
> have decided against doing so, fix-cm and scalefnt packages will not be 
> needed after all. cvs reflects the change.
Good, thanks.
> Please tell me though, that the fontenc and textcomp packages ARE included. 
> They are not essential to the changes I made last night, but I think these 
> packages will fix the dvipng problem we had where a few of the glyphs were 
> not properly interpretted on screen and in png output. 
I suspect those are fine, because fix-cm was the only problem I hit, and this 
was on a fresh ubuntu install, with nothing in the way of manual tweaks. But 
it may be a good idea to wait and hear confirmation from users of other TeX 
distros (such as those on win32).
Cheers,
f

On Monday 30 January 2006 12:47 am, Fernando Perez wrote:
> ! LaTeX Error: File `fix-cm.sty' not found.
[...]
> I grabbed fix-cm by hand from CTAN:
>
> http://www.ctan.org/info?id=fix-cm
>
> and things seem to work now, but I suspect you didn't intend people to have 
> to go fishing into CTAN :)
Thanks Fernando. No, I do NOT want anyone to have to visit CTAN to make this 
work. I added this when I was considering scaling the fonts in latex. Since I 
have decided against doing so, fix-cm and scalefnt packages will not be 
needed after all. cvs reflects the change.
Please tell me though, that the fontenc and textcomp packages ARE included. 
They are not essential to the changes I made last night, but I think these 
packages will fix the dvipng problem we had where a few of the glyphs were 
not properly interpretted on screen and in png output. 
Darren

Hi Ted,
Ted Drain wrote:
> Fernando,
> This looks like you're using the Tk backend. This is one of the problems 
> with trying to use a very common method name in widgets like 
> resize(). Different GUI packages can define it differently. It looks like 
> Tk uses this for it's resize event handling while Gtk and Qt use resize( w, 
> h ) for controlling size and other method names for the event handling like 
> resizeEvent().
> 
> After some digging, I think this looks like it might be a bug (or at least 
> a head ache) in the Tk backend design. In backend_bases.py, there is this 
> code:
[snip detailed look at the problem]
Thanks for the detective work: I was mostly reporting the issue as a TkAgg 
backend user. I certainly hope that the backend developers can use your info 
and track this problem down in a clean manner, as this is obviously broken, 
but I don't know anything about Tk either (I just use it), so I'm afraid I 
won't be the one doing the work :)
Cheers,
f

Darren Dale wrote:
> I just made a big commit to cvs. With these changes, the font.latex.package rc 
> setting is no longer needed, and should be removed from ones personal 
> matplotlibrc file.
I wonder if I'm doing something wrong. I built fresh from CVS on an Ubuntu 
box, nuked my tex.cache directory, and yet a simple plot(range(10)) gives me:
/usr/local/lib/python2.4/site-packages/matplotlib/texmanager.py in 
get_rgba(self=<matplotlib.texmanager.TexManager instance>, tex='0', 
fontsize=12.0, dpi=96.0, rgb=(0, 0, 0))
 385 # force=True to skip cacheing while debugging
 386 pngfile = self.make_png(tex, dpi, force=False)
--> 387 X = readpng(pngfile)
 X = undefined
 global readpng = <built-in method readpng of tuple object at 0x4071318c>
 pngfile = 
'/home/fperez/.matplotlib/tex.cache/f43bbaa78e0a6e5688e327d12df8b9ce_96.png'
 388 vers = self.get_dvipng_version()
 389 #print 'dvipng version', vers
RuntimeError: _image_module::readpng could not open PNG file 
/home/fperez/.matplotlib/tex.cache/f43bbaa78e0a6e5688e327d12df8b9ce_96.png for 
reading
The png is indeed not there at all. Am I missing something? if the png 
didn't get created, shouldn't make_png raise an exception instead?
I tried to compile the latex file by hand, but even that fails:
maqroll[tex.cache]> latex f43bbaa78e0a6e5688e327d12df8b9ce.tex
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5)
entering extended mode
(./f43bbaa78e0a6e5688e327d12df8b9ce.tex
LaTeX2e <2001年06月01日>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, catalan, croatian, czech, danish, dutch, finnish, greek, iceland
ic, irish, italian, latin, magyar, norsk, norsk, portuges, romanian, russian, s
lovak, slovene, spanish, swedish, turkish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001年04月21日 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/usr/share/texmf/tex/latex/misc/type1cm.sty)
(/usr/share/texmf/tex/latex/psnfss/helvet.sty
(/usr/share/texmf/tex/latex/graphics/keyval.sty))
(/usr/share/texmf/tex/latex/psnfss/courier.sty)
! LaTeX Error: File `fix-cm.sty' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)
Enter file name: X
The problem is that fix-cm.sty is NOT part of a standard latex distribution. 
Did you add this yourself? I checked my destkop (Fedora 3 box):
abdul[src]> locate fix-cm
abdul[src]>
I grabbed fix-cm by hand from CTAN:
http://www.ctan.org/info?id=fix-cm
and things seem to work now, but I suspect you didn't intend people to have to 
go fishing into CTAN :)
I'll keep testing and will let you know if I hit any other snags. Thanks a 
lot for all your work!
f
Cheers,
f

I just made a big commit to cvs. With these changes, the font.latex.package rc 
setting is no longer needed, and should be removed from ones personal 
matplotlibrc file.
I changed the texmanager to read the serif, sans-serif, monospace, and cursive 
rc parameters. It looks until it finds a font that it recognizes, and 
defaults to computer modern.
Here are the currently supported latex fonts:
- serif: Times, Palatino, Bookman, New Century Schoolbook, Charter, Computer 
Modern Roman (Times and Palatino have their own math fonts, the others 
default to computer modern math fonts)
- sans-serif: Helvetica, Avant Garde, Computer Modern Sans Serif (I added 
Avant Garde to the matplotlibrc.template)
- monospace: Courier, Computer Modern Typewriter
- cursive: Zapf Chancery
I've tested all of these, and everything appears to be working. The 
font.family setting is still respected, and cursive is now supported with 
latex, but fantasy is not (raises a warning, defaults to serif). If you use 
the usetex option, please kick the tires and let me know how it goes. Once 
everything is satisfactory, I would like to request a minor version bump, so 
I can update the wiki.
John, I made that change in backend_agg, so it uses the same information as 
texmanager to generate its keys. I decided against scaling the fonts in 
latex. There is a good reason to keep the scaling as it is: smaller 
tex.cache. If I had changed it, I would have had to cache the same text 
multiple times for each new fontsize.
Darren

Hi all,
I'm attaching a set of files which provide very nice arrows functionality. 
This was contributed by Rob Knight, from the biochemistry dept. at the 
University of Colorado, Boulder.
The attachments are:
- arrow_plot: example file to run, which should open a plot window and 
generate a png.
- fancy_arrow: actual module with the functionality, meant for merging into 
matplotlib if you guys like it. Obviously the examples will need to be 
changed once this becomes part of mpl.
- arrow_cgi: example for this as CGI code. This can be seen in action here:
http://bayes.colorado.edu/cgi-bin/arrows/arrow_cgi.py
- a PNG of what the results should look like. I just generated this a minute 
ago on my box, using CVS matplotlib (Rob, it looks fine to me, so the glitches 
you were seeing were either just on your system, or have been fixed in CVS).
Chris Barker was interested in playing with this. I hope either him or others 
can integrate it smoothly into the rest of matplotlib, and that it may 
eventually give us better arrows capabilities than quiver.
Thanks to Rob for putting this code out!
Cheers,
f

I don't see a need for TeX support, especially if it is taking very much ef=
fort.
I agree that font specification could be a little easier.
If a user was concerned with figure fonts matching the body fonts of a
LaTeX document, there should be a clear mapping from matplotlibrc
settings to which package to include in their LaTeX preamble and how
to set up their document.
Other than that, I don't care how its done and would want to make it
as easy as possible for the developer(s).
(Do you realize that it takes me several second of concentrated effort
to type LaTeX instead of latex and I don't really know why I keep
doing it?)
Ryan
On 1/29/06, Fernando Perez <Fer...@co...> wrote:
> Darren Dale wrote:
>
> > The table may not be necessary: I just discovered that we can drop the
> > font.latex.package rc setting, and instead respect the serif,
> > font.sans-serif, cursive and monospace font rc settings.
> >
> > For example, if "times" is first in my font.serif list (or the first on=
e found
> > that latex supports), this command can be run:
> >
> > \renewcommand{\rmdefault}{ptm}
> >
> > but if font.family is cursive in rc, then Zapf Chancery (pzc) is used i=
nstead.
> >
> > Which entry in matplotlibrc should correspond to the computer modern fo=
nts? Is
> > it "serif" for font.serif?
> >
> > Also, I would like to drop support for the tex engine, and focus on lat=
ex
> > only. These font issues we are addressing are beyond my ability (and
> > interest) to support with tex, but they can be handled using the availa=
ble
> > font packages with latex. Objections?
>
> I'm +1 on anything that simplifies this: while the functionality is fanta=
stic,
> the current usability 'leaves to be desired' :). And many thanks for yo=
ur
> combined efforts on this problem!
>
> Best,
>
> f
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

All,
CVS now has some changes that need testing:
1) ticker.AutoLocator is using a new MaxNLocator originating in a 
suggested algorithm by Rob Knight. I don't expect it to do *exactly* 
what the original AutoLocator does, but it should be similar, and about 
as good. If so, then in the future it will facilitate better control of 
the number of ticks on an axis. Please try it with your most 
pathological axis examples as well as normal use cases. You can test it 
with any plot command, because AutoLocator is used by default.
2) The MaxNLocator is now used in contour to select the contour levels 
when they are not given explicitly. Previously the levels would be 
linearly distributed between the data extremes; now they land on nice 
values, like "0.0" instead of "0.1379".
Eric

Darren Dale wrote:
> The table may not be necessary: I just discovered that we can drop the 
> font.latex.package rc setting, and instead respect the serif, 
> font.sans-serif, cursive and monospace font rc settings. 
> 
> For example, if "times" is first in my font.serif list (or the first one found 
> that latex supports), this command can be run:
> 
> \renewcommand{\rmdefault}{ptm}
> 
> but if font.family is cursive in rc, then Zapf Chancery (pzc) is used instead.
> 
> Which entry in matplotlibrc should correspond to the computer modern fonts? Is 
> it "serif" for font.serif?
> 
> Also, I would like to drop support for the tex engine, and focus on latex 
> only. These font issues we are addressing are beyond my ability (and 
> interest) to support with tex, but they can be handled using the available 
> font packages with latex. Objections?
I'm +1 on anything that simplifies this: while the functionality is fantastic, 
the current usability 'leaves to be desired' :). And many thanks for your 
combined efforts on this problem!
Best,
f

I'm moving this over to matplotlib-devel for the time being. There are a 
couple of technical details I need to discuss that dont need to be broadcast 
to matplotlib-user's 384 (!) subscribers. We are discussing how usetex 
handles different font families.
On Sunday 29 January 2006 4:07 pm, you wrote:
> Darren Dale wrote:
> > Earlier this morning I changed the wiki page to explain this detail. Is
> > it still unclear?
>
> mmh. Perhaps a little summary table of the kind
>
> font.family || font.latex.package || resulting font
> -------------------------------------------------------
> serif || various options
>
> serif
>
> sans
>
> sans
>
> etc.
>
>
> Might help the dense amongst us make sense of the various possible results
> without having to think, something at least I am not very good at.
:) I'm pretty dense even after my third cup of coffee.
The table may not be necessary: I just discovered that we can drop the 
font.latex.package rc setting, and instead respect the serif, 
font.sans-serif, cursive and monospace font rc settings. 
For example, if "times" is first in my font.serif list (or the first one found 
that latex supports), this command can be run:
\renewcommand{\rmdefault}{ptm}
but if font.family is cursive in rc, then Zapf Chancery (pzc) is used instead.
Which entry in matplotlibrc should correspond to the computer modern fonts? Is 
it "serif" for font.serif?
Also, I would like to drop support for the tex engine, and focus on latex 
only. These font issues we are addressing are beyond my ability (and 
interest) to support with tex, but they can be handled using the available 
font packages with latex. Objections?
John, I learned today how to properly scale fonts, which might fix some of the 
problems people have reported with text that is not being placed properly. It 
requires using at least the scalefnt and fix-cm packages. I believe they are 
included in every latex distribution. We currently do 10pt in latex, and then 
scale everything afterwards, because that was the only way it seemed to work. 
What we should do is just scale the fonts in latex and then we dont have to 
monkey with the results. Do you object to this change?
Darren

Matthew Brett wrote:
>Hi,
>
>I noticed the recent call to update the new SciPy website on the
>numpy-discuss list:
>
>http://sourceforge.net/mailarchive/forum.php?thread_id=9585553&forum_id=4890
>
>On the documentation page:
>
>http://new.scipy.org/Wiki/Documentation
>
>there is:
>
>http://new.scipy.org/Wiki/Plotting_Tutorial
>
>which has no content at the moment. 
>
OK, I put up a bare-bones page there now. Feel free to extend it.
> You are otherwise pointed to the
>old page which lists plt, gplt etc scipy libraries.
>
The 3(!) old scipy plotting libraries have all been removed mainline
scipy. Matplotlib happily made this the obvious choice. The old packages
are in the scipy sandbox now, for anyone needing them.
Can you please list where these old references are? Perhaps you could
start a page on the wiki to collect things that need to be updated
there. We need to go through and update examples to matplotlib.
> I wondered what
>the current thinking was on SciPy and plotting. Is it time to suggest
>that SciPy users go straight to matplotlib?
> 
>
Yes! :)

That is pretty much what is suggested on the scipy mailling list.
On 1/29/06, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> I noticed the recent call to update the new SciPy website on the
> numpy-discuss list:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D9585553&forum_id=
=3D4890
>
> On the documentation page:
>
> http://new.scipy.org/Wiki/Documentation
>
> there is:
>
> http://new.scipy.org/Wiki/Plotting_Tutorial
>
> which has no content at the moment. You are otherwise pointed to the
> old page which lists plt, gplt etc scipy libraries. I wondered what
> the current thinking was on SciPy and plotting. Is it time to suggest
> that SciPy users go straight to matplotlib?
>
> Just a thought,
>
> Matthew
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
I noticed the recent call to update the new SciPy website on the
numpy-discuss list:
http://sourceforge.net/mailarchive/forum.php?thread_id=3D9585553&forum_id=
=3D4890
On the documentation page:
http://new.scipy.org/Wiki/Documentation
there is:
http://new.scipy.org/Wiki/Plotting_Tutorial
which has no content at the moment. You are otherwise pointed to the
old page which lists plt, gplt etc scipy libraries. I wondered what
the current thinking was on SciPy and plotting. Is it time to suggest
that SciPy users go straight to matplotlib?
Just a thought,
Matthew

On Friday 27 January 2006 09:50, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I would like to use verbose.report during the rc
> Darren> validation process to fix this. The problem is that
> Darren> verbose is initialized as 'silent', and is only changed to
> Darren> the user-selected level after the rest of the rc-file has
> Darren> been read. One solution might be to move the verbose
> Darren> entries to the top of matplotlibrc, another might be to
> Darren> modify __init__.py to validate the verbose settings first,
> Darren> no matter where they are located in the matplotlibrc. I
> Darren> favor the second approach.
>
> Darren> Thoughts, opinions, suggestions?
>
> I am not in favor of moving them to the top, since I like to have the
> most commonly changed ones there. Nor am I wild about a 2 pass
> approach.
>
> Would it work for you to buffer the rc messages during initialization,
> and then output them at the end of the rc read depending on the
> verbose settings?
changed in cvs

Fernando,
This looks like you're using the Tk backend. This is one of the problems 
with trying to use a very common method name in widgets like 
resize(). Different GUI packages can define it differently. It looks like 
Tk uses this for it's resize event handling while Gtk and Qt use resize( w, 
h ) for controlling size and other method names for the event handling like 
resizeEvent().
After some digging, I think this looks like it might be a bug (or at least 
a head ache) in the Tk backend design. In backend_bases.py, there is this 
code:
class FigureCanvasBase:
 ...
 def resize(self, w, h):
 """
 set the canvas size in pixels
 """
 pass
Presumably, this is sort of a default implementation for a virtual method 
that others can rely on. However, in backends/backend_tkagg.py we have this:
class FigureCanvasTkAgg(FigureCanvasAgg):
 ...
 def resize(self, event):
 width, height = event.width, event.height
 ...
And if you look in backends/backend_agg.py you'll see this:
class FigureCanvasAgg(FigureCanvasBase):
 ...
So FigureCanvasTkAgg is inheriting from FigureCanvasAgg which inherits from 
FigureCanvasBase which has a resize( w, h ) method. However, 
FigureCanvasTkAgg re-implements resize with a different signature. At best 
this very confusing.
It looks like FigureCanvasTkAgg.resize is used as a callback in the ctor 
for that class for one of the Tk events. Here's what I'd suggest:
1) Rename FigureCanvasTkAgg.resize( event ) to FigureCanvasTkAgg.resize( w, 
h ).
2) Move the code that extracts the w, h from the event to a new method 
FigureCanvasTkAgg.resizeEvent( event ) like this:
class FigureCanvasTkAgg:
 def resizeEvent(self, event):
 width, height = event.width, event.height
 if self._resize_callback is not None:
 self._resize_callback(event)
 self.resize( width, height )
3) Change the FigureCanvasTkAgg ctor to use the resizeEvent callback 
instead of resize.
WARNING: I don't know anything about Tk! I'm hoping someone that does now 
Tk can check this over and make sure it sounds right.
This of course doesn't actually do anything for fixing the problem we've 
been discussing about how to resize a plot after it's been created and have 
the window update accordingly.
Ted
At 11:08 AM 1/25/2006, Fernando Perez wrote:
>Ted Drain wrote:
>>Maybe one of you guys could refresh my memory. What is the calling 
>>sequence we're going for?
>
>My original message was this:
>
>============================================================================
>In [1]: gcf().set_figsize_inches((8,8),forward=True)
>---------------------------------------------------------------------------
>exceptions.TypeError Traceback (most recent
>call last)
>
>/home/fperez/code/python/pylab/arrows/<ipython console>
>
>/usr/lib/python2.3/site-packages/matplotlib/figure.py in
>set_figsize_inches(self, *args, **kwargs)
> 266 canvasw = w*dpival
> 267 canvash = h*dpival
>--> 268 self.canvas.resize(int(canvasw), int(canvash))
> 269
> 270 def get_size_inches(self):
>
>TypeError: resize() takes exactly 2 arguments (3 given)
>
>
>A quick look at the backends code shows this:
>
> def resize(self, event):
> width, height = event.width, event.height
> self.toolbar.configure(width=width) # , height=height)
>
>So quite obviously, this doesn't work: it's expecting an event object, and a
>pair of numbers is being passed.
>
>I'm not sure what the proper fix should be here, I don't really know the code
>flow well enough.
>
>I should also note that the gcf().set_figsize_inches((8,8),forward=True) seems
>to produce a different on-screen result per backend (in some it doesn't do
>anything, in Qt it stretches the figure only horizontally, ...) That code
>seems to be pretty much broken.
>
>I noticed that figure(figsize=(8,8)) seems to work fine, but I'm not sure how
>to programmatically resize an existing figure, given the above problems.
>============================================================================
>
>Beyond this, I'll leave it to the backend experts as to what the right 
>choices should be. I just noted that shipping a feature _known_ to break 
>on all but one backend doesn't sound like the best approach :)
>
>Cheers,
>
>f
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On Friday 27 January 2006 09:50, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I would like to use verbose.report during the rc
> Darren> validation process to fix this. The problem is that
> Darren> verbose is initialized as 'silent', and is only changed to
> Darren> the user-selected level after the rest of the rc-file has
> Darren> been read. One solution might be to move the verbose
> Darren> entries to the top of matplotlibrc, another might be to
> Darren> modify __init__.py to validate the verbose settings first,
> Darren> no matter where they are located in the matplotlibrc. I
> Darren> favor the second approach.
>
> Darren> Thoughts, opinions, suggestions?
>
> I am not in favor of moving them to the top, since I like to have the
> most commonly changed ones there. Nor am I wild about a 2 pass
> approach.
>
> Would it work for you to buffer the rc messages during initialization,
> and then output them at the end of the rc read depending on the
> verbose settings?
That's a good idea. I'll work on it as soon as I get a chance, probably 
tomorrow morning.
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I would like to use verbose.report during the rc
 Darren> validation process to fix this. The problem is that
 Darren> verbose is initialized as 'silent', and is only changed to
 Darren> the user-selected level after the rest of the rc-file has
 Darren> been read. One solution might be to move the verbose
 Darren> entries to the top of matplotlibrc, another might be to
 Darren> modify __init__.py to validate the verbose settings first,
 Darren> no matter where they are located in the matplotlibrc. I
 Darren> favor the second approach.
 Darren> Thoughts, opinions, suggestions?
I am not in favor of moving them to the top, since I like to have the
most commonly changed ones there. Nor am I wild about a 2 pass
approach.
Would it work for you to buffer the rc messages during initialization,
and then output them at the end of the rc read depending on the
verbose settings?
JDH

On Friday 27 January 2006 07:04, Darren Dale wrote:
> On Friday 27 January 2006 6:58 am, Nils Wagner wrote:
> > Is it possible to disable this message when importing matplotlib ?
> >
> > >>> import matplotlib
> >
> > /usr/lib64/python2.4/site-packages/matplotlib/__init__.py:729:
> > UserWarning: ghostscript-8.15 found. ghostscript-8.16 or later is
> > recommended for use with the text.usetex option.
> > warnings.warn( 'ghostscript-%s found. ghostscript-%s or later is \
>
> Not at present. I wanted to make this warning a call to verbose.report, but
> couldnt get it to work. The report was not printed. I'll look into it again
> this morning.
I would like to use verbose.report during the rc validation process to fix 
this. The problem is that verbose is initialized as 'silent', and is only 
changed to the user-selected level after the rest of the rc-file has been 
read. One solution might be to move the verbose entries to the top of 
matplotlibrc, another might be to modify __init__.py to validate the verbose 
settings first, no matter where they are located in the matplotlibrc. I favor 
the second approach.
Thoughts, opinions, suggestions?

Tested on Solaris8/Python 2.3.4, RHEL3/Python2.4,
MacOSX 10.3.9/Python2.4 - no problems.
Thanks for making the change!
Nadia
> 
> Committed. Please test. This REALLY cleans up the setup.py file. 
> Should hopefully address the building non-eggs with setuptools issue.
> 
> Thanks again,
> Charlie
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Robert Kern wrote:
> The problem with this approach is that people using easy_install to grab sources
> and build an egg won't be able to see the extra information that is being put
> into setup_bdist_egg.py and might be crucial to specifying dependencies. I like
> Andrew's approach better, for mpl and ipython, too. I wish I'd thought of it myself.
OK: I'll leave it to you eggsperts to sort out the finer points of this 
problem. As long as mpl doesn't silently pull in setuptools anymore, I'm 
happy as a puppy.
Cheers,
f

Well, after the changes today the only setuptools modification to the
setup.py file is the addition of the "namespace_packages =3D
['matplotlib.toolkits']" for basemap support and eggs. So I think the
`python setup_bdist_egg.py` is a good idea. I'll add it barring any
objections (which I doubt there will be).
- Charlie
On 1/26/06, Fernando Perez <Fer...@co...> wrote:
> Andrew Straw wrote:
> > I'm myself not 100% sure we want to use this patch, but I think perhaps
> > it's better -- people who happen to have setuptools installed don't get
> > setuptools-built packages unless they ask for them.
>
> which is a big plus: recently I couldn't get matplotlib to install with a
> plain 'setup.py install' because setuptools was found in my path, but bro=
ken
> (as it seems to be most of the time for me: I hate setuptools with a pass=
ion,
> for reasons too long to get into right now).
>
> Making sure that the mere _presence_ of setuptools in your path doesn't a=
ll of
> a sudden break all manner of things for matplotlib is a big plus.
>
> You could always ship a little script specifically to build the egg, alon=
g the
> lines of
>
> http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setup_bdi=
st_egg.py
>
> Normal builds would be uncontaminated by setuptools, and those who happen=
 to
> like it can just call
>
> python setup_bdist_egg.py
>
> instead of
>
> python setup.py bdist_egg
>
>
> In the interest of robustness for matplotlib, I think that sandboxing
> setuptools a little more is a good idea.
>
> Cheers,
>
> f
>

Fernando Perez wrote:
> Nadezhda Dencheva wrote:
> 
>> What's wrong with Pete Shinners's smart_istall_data?
>> I am thinking of using it in all our packages, so
>> if someone knows of any drawbacks I'd like to hear
>> about this.
>>
>> I've spent hours trying to construct a distutils hack that
>> will force bdist_wininst to package data correctly and this
>> one just works, (that's why I'm so impressed).
> 
> It seems you guys have found a solution already, but just in case it's
> of any use (now or later), you may want to glance at
> 
> http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setupext
> 
> This little snippet of code was contributed to ipython long ago, to
> assist with data packaging (compatible with python 2.2, including
> bdist_rpm and bdist_wininst).
My understanding is that both solutions use essentially the same technique for
emulating package_data. The major difference is that the extension in ipython
allows you to specify some data to go wherever --install-data points and some
other data to go into the package itself. I don't think mpl has such a split.
And I don't think it should have one, either!
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

Fernando Perez wrote:
> Andrew Straw wrote:
> 
>> I'm myself not 100% sure we want to use this patch, but I think perhaps
>> it's better -- people who happen to have setuptools installed don't get
>> setuptools-built packages unless they ask for them.
> 
> which is a big plus: recently I couldn't get matplotlib to install with
> a plain 'setup.py install' because setuptools was found in my path, but
> broken (as it seems to be most of the time for me: I hate setuptools
> with a passion, for reasons too long to get into right now).
> 
> Making sure that the mere _presence_ of setuptools in your path doesn't
> all of a sudden break all manner of things for matplotlib is a big plus.
> 
> You could always ship a little script specifically to build the egg,
> along the lines of
> 
> http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/setup_bdist_egg.py
> 
> Normal builds would be uncontaminated by setuptools, and those who
> happen to like it can just call
> 
> python setup_bdist_egg.py
> 
> instead of
> 
> python setup.py bdist_egg
The problem with this approach is that people using easy_install to grab sources
and build an egg won't be able to see the extra information that is being put
into setup_bdist_egg.py and might be crucial to specifying dependencies. I like
Andrew's approach better, for mpl and ipython, too. I wish I'd thought of it myself.
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter