matplotlib-devel Mailing List for matplotlib

Charlie Moad wrote:
> 2. Can anyone test this on 10.4? 
> http://dev.imamuseum.org/~cmoad/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg
I downloaded this, and did:
$ easy_install matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg
and got what I enclosed below.
The short version: it went and found the source from pypi, and built it 
on my machine. The build appears to work fine. However, I do have 
freetype and libpng. It would have presumably failed otherwise.
Was it supposed to install a binary?
OS-X 10.4.10 PPC Dual G5.
Python2.5 Universal Framework build from pythonmac.org/packages
-Chris
Processing matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg
creating 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg
Extracting matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg to 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
Removing matplotlib 0.90.1-r4407 from easy-install.pth file
Adding matplotlib 0.91.0 to easy-install.pth file
Installed 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg
Processing dependencies for matplotlib==0.91.0
Searching for matplotlib==0.91.0
Reading http://cheeseshop.python.org/pypi/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading http://cheeseshop.python.org/pypi/matplotlib/0.91.0
Best match: matplotlib 0.91.0
Downloading 
http://pypi.python.org/packages/source/m/matplotlib/matplotlib-0.91.0.tar.gz#md5=059aa32556644760aef9cec9fb8fc3ac
Processing matplotlib-0.91.0.tar.gz
Running matplotlib-0.91.0/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-8sWQab/matplotlib-0.91.0/egg-dist-tmp-I3Dgc1
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.91.0
 python: 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1
 (Apple Computer, Inc. build 5341)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.0.3.1
 freetype2: found, but unknown version (no pkg-config)
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.4.0
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be 
able
 * to "import gtk" in your build/install environment
 Qt: no
 Qt4: no
 Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: matplotlib will provide
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: 7.07.1
 latex: 3.141592
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: matplotlib will provide
 enthought.traits: matplotlib will provide
[Edit setup.cfg to suppress the above messages]
============================================================================
warning: no files found matching 'NUMARRAY_ISSUES'
warning: no files found matching 'MANIFEST'
warning: no files found matching 'matplotlibrc'
warning: no files found matching 'lib/matplotlib/toolkits'
no previously-included directories found matching 'examples/_tmp_*'
i686-apple-darwin8-gcc-4.0.1: powerpc-apple-darwin8-gcc-4.0.1: 
-framework: linker input file unused because linking not done
i686-apple-darwin8-gcc-4.0.1: Tcl: linker input file unused because 
linking not done
i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused 
because linking not done
i686-apple-darwin8-gcc-4.0.1: Tk: linker input file unused because 
linking not done
-framework: linker input file unused because linking not done
powerpc-apple-darwin8-gcc-4.0.1: Tcl: linker input file unused because 
linking not done
powerpc-apple-darwin8-gcc-4.0.1: -framework: linker input file unused 
because linking not done
powerpc-apple-darwin8-gcc-4.0.1: Tk: linker input file unused because 
linking not done
zip_safe flag not set; analyzing archive contents...
dateutil.zoneinfo.__init__: module references __file__
enthought.etsconfig.etsconfig: module references __file__
enthought.traits.trait_db: module MAY be using inspect.stack
enthought.traits.ui.tk.helper: module references __file__
enthought.traits.ui.tk.image_enum_editor: module references __file__
matplotlib.__init__: module references __file__
matplotlib.pyparsing: module MAY be using inspect.stack
matplotlib.backends.backend_cocoaagg: module references __file__
matplotlib.config.cutils: module references __file__
pytz.__init__: module references __file__
pytz.tzfile: module references __file__
Removing matplotlib 0.91.0 from easy-install.pth file
Adding matplotlib 0.91.0 to easy-install.pth file
Installed 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.91.0-py2.5-macosx-10.3-fat.egg
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/image.cpp') in <bound method CleanUpFile.__del__ of 
<setupext.CleanUpFile instance at 0x1659f58>> ignored
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/transforms.cpp') in <bound method CleanUpFile.__del__ of 
<setupext.CleanUpFile instance at 0x16598f0>> ignored
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of 
<setupext.CleanUpFile instance at 0x1659c60>> ignored
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Nov 28, 2007 2:21 PM, Michael Droettboom <md...@st...> wrote:
> I suppose this was bound to happen...
>
> The released version has a bug that prevents using the (serif) STIX
> fonts. Entirely my fault for not checking all font possibilities after
> a recent change.
>
> r4492 fixes this bug.
>
> Let me know how you want to proceed... I'm happy to help cutting
> another release if we decide to do that.
I think we should wait until we've had a chance to collect a few bugs
first... We'll announce on mpl-users, and after a few days to give
bugs a chance to filter in, we'll cut 90.1, and then announce to a
wider audience, eg python-list.
JDH

I suppose this was bound to happen...
The released version has a bug that prevents using the (serif) STIX
fonts. Entirely my fault for not checking all font possibilities after
a recent change.
r4492 fixes this bug.
Let me know how you want to proceed... I'm happy to help cutting
another release if we decide to do that.
Sorry,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Nov 28, 2007 1:07 PM, Michael Droettboom <md...@st...> wrote:
>> Great work everyone with getting the release out!
>>
>> Now is probably a good time to discuss how the SVN repository will look
>> after the release.
>>
>> My thoughts are below -- any and all concerns or suggestions are
>> welcome. I'm happy to do this work, and will probably wait until next
>> week sometime to give the release some time to cool off, in case a major
>> stopper bug is discovered in the meantime. A lot of this is perhaps
>> obvious, but it doesn't hurt to be specific ;)
>>
>> PLAN:
>>
>> 1. Create a new branch based on the release version (I think Charlie
>> last put it at r4477), in "branches/RELEASE_0_91_0". This branch will
>> be "locked" to provide a little speedbump to remind us not to commit to
>> it. This branch is useful to have as a point of comparison -- though
>> not strictly necessary, since we know the release version on the trunk.
> 
> Bearing in mind that I am a branch newbie, this seems a bit overly
> complicated. I envisioned having a single branch which would be the
> svn trunk before you merge your transforms in. Call this MAINTAIN_91
> or something like that. Then merge the transforms branch into the
> trunk, and close or move the transforms branch as you see fit.
> 
> That way we have one active branch (the 0.91 maintenance) and one
> trunk. I don't see the benefit of having RELEASE_0_91_0 and MAINT_0_x
> branches, since we can use use -r checkouts to get 0.91.0 right?
> Basically, I hope we can get by w/o multiple branches for the 91
> maintenance. But feel free to educate me :-)
You're correct -- it isn't strictly necessary. IMHO, however, it makes 
the released 0.91 version more obvious. As it stands now, one has to 
know to look for the revision associated with 0.91 in the CHANGELOG. 
It's an attempt to follow standard SVN practice to make things easier 
for someone coming into the project.
Which leads me to a "Doh!" -- it should be under "tags", rather than 
under "branches". (Of course, in SVN there's no difference, other than 
the name...)
I also should revise these names to fit in with the mpl's tags brought 
over from CVS:
 branches/RELEASE_0_91_0 ---> tags/v0_91_0
 branches/MAINT_0_x ---> branches/v0_91_maint
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 28, 2007 1:07 PM, Michael Droettboom <md...@st...> wrote:
> Great work everyone with getting the release out!
>
> Now is probably a good time to discuss how the SVN repository will look
> after the release.
>
> My thoughts are below -- any and all concerns or suggestions are
> welcome. I'm happy to do this work, and will probably wait until next
> week sometime to give the release some time to cool off, in case a major
> stopper bug is discovered in the meantime. A lot of this is perhaps
> obvious, but it doesn't hurt to be specific ;)
>
> PLAN:
>
> 1. Create a new branch based on the release version (I think Charlie
> last put it at r4477), in "branches/RELEASE_0_91_0". This branch will
> be "locked" to provide a little speedbump to remind us not to commit to
> it. This branch is useful to have as a point of comparison -- though
> not strictly necessary, since we know the release version on the trunk.
Bearing in mind that I am a branch newbie, this seems a bit overly
complicated. I envisioned having a single branch which would be the
svn trunk before you merge your transforms in. Call this MAINTAIN_91
or something like that. Then merge the transforms branch into the
trunk, and close or move the transforms branch as you see fit.
That way we have one active branch (the 0.91 maintenance) and one
trunk. I don't see the benefit of having RELEASE_0_91_0 and MAINT_0_x
 branches, since we can use use -r checkouts to get 0.91.0 right?
Basically, I hope we can get by w/o multiple branches for the 91
maintenance. But feel free to educate me :-)
JDH

On Wednesday 28 November 2007 01:12:00 pm John Hunter wrote:
> On Nov 28, 2007 11:46 AM, Eric Firing <ef...@ha...> wrote:
> > I assume there is also some sort of C and/or C++ mode, and similar hook
> > additions are needed for them--correct? Or is there a hierarchy of
> > modes, in which case a single hook could go at a higher level?
>
> I don't know about a hierarchy, but there is a c++-mode-hook and a
> c-mode-hook. I've updated the CODING_GUIDE to advise emacs users to
> set these hooks. Soon your nightmare of trailing whitespaces will be
> nothing more than a nasty memory ....
Am I the only one who never got comfortable using emacs?

Great work everyone with getting the release out!
Now is probably a good time to discuss how the SVN repository will look 
after the release.
My thoughts are below -- any and all concerns or suggestions are 
welcome. I'm happy to do this work, and will probably wait until next 
week sometime to give the release some time to cool off, in case a major 
stopper bug is discovered in the meantime. A lot of this is perhaps 
obvious, but it doesn't hurt to be specific ;)
PLAN:
1. Create a new branch based on the release version (I think Charlie 
last put it at r4477), in "branches/RELEASE_0_91_0". This branch will 
be "locked" to provide a little speedbump to remind us not to commit to 
it. This branch is useful to have as a point of comparison -- though 
not strictly necessary, since we know the release version on the trunk.
2. Create a new branch based on the head of the trunk, in 
"branches/MAINT_0_x". This will be used for bug fixes to the 0.x tree. 
 It may get copied into "branches/RELEASE_0_91_1" (or some such) in the 
future, if we want to make a bugfix release without the transforms changes.
3. Setup the svnmerge.py properties so that it is easy to merge bugfixes 
on MAINT_0_x back into the trunk. (This is the "Merging branches back 
to trunk" case in [1]).
4. Merge "branches/transforms" back into "trunk". All developers who 
currently have the trunk checked out will transparently be moved to the 
new transforms branch on their next "svn up".
5. Move "branches/transforms" to "branches/closed/transforms" (or 
"closed_branches/transforms", if you prefer). There are two minds about 
moving or deleting closed branches, but personally, I like to retain 
them to make it easier to find history within the branch.
One possible downside of this plan is with anyone committing while I do 
this. It's easy enough to lock things while I do all this, but that may 
inconvenience some. Any suggestions about making the transition 
smoother are welcome.
[1] Svnmerge.py documentation. 
http://www.orcaware.com/svn/wiki/Svnmerge.py#Quick_Usage_Overview
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 28, 2007 12:22 PM, Michael Droettboom <md...@st...> wrote:
> So, I think perhaps this description in CODING_GUIDE is backward, but
> wanted to double check before I fix it.
Yep, good catch. I updated the doc. I think I have it this time...
Please do not commit lines with trailing white space, as it causes
noise in svn diffs. If you are an emacs user, the following in your
.emacs will cause emacs to strip trailing white space on save for
python, C and C++
; and similarly for c++-mode-hook and c-mode-hook
(add-hook 'python-mode-hook
 (lambda ()
	 (add-hook 'write-file-functions 'delete-trailing-whitespace)))
for older versions of emacs (emacs<22) you need to do
(add-hook 'python-mode-hook
 (lambda ()
 (add-hook 'local-write-file-hooks 'delete-trailing-whitespace)))

I think the emacs version dependency in the CODING_GUIDE may be backward.
AFAIK, "write-file-functions" is the current one to use for emacs 22
(the latest released version) and beyond. "local-write-file-hooks" is
the old deprecated way.
The docstring for local-write-file-hooks is:
"This variable is obsolete since 22.1; use `write-file-functions' instead."
So, I think perhaps this description in CODING_GUIDE is backward, but
wanted to double check before I fix it.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
John Hunter wrote:
> On Nov 28, 2007 11:46 AM, Eric Firing <ef...@ha...> wrote:
> 
>> I assume there is also some sort of C and/or C++ mode, and similar hook
>> additions are needed for them--correct? Or is there a hierarchy of
>> modes, in which case a single hook could go at a higher level?
> 
> I don't know about a hierarchy, but there is a c++-mode-hook and a
> c-mode-hook. I've updated the CODING_GUIDE to advise emacs users to
> set these hooks. Soon your nightmare of trailing whitespaces will be
> nothing more than a nasty memory ....
> 
> JDH
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> 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

On Nov 28, 2007 11:46 AM, Eric Firing <ef...@ha...> wrote:
> I assume there is also some sort of C and/or C++ mode, and similar hook
> additions are needed for them--correct? Or is there a hierarchy of
> modes, in which case a single hook could go at a higher level?
I don't know about a hierarchy, but there is a c++-mode-hook and a
c-mode-hook. I've updated the CODING_GUIDE to advise emacs users to
set these hooks. Soon your nightmare of trailing whitespaces will be
nothing more than a nasty memory ....
JDH

John Hunter wrote:
> On Nov 21, 2007 1:52 PM, Andrew Straw <str...@as...> wrote:
>> Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
>> Looks like I'll now have to find a way to do the one thing in emacs that
>> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
> 
> I think I may have found the ultimate emacs solution. It really
> annoys me to see the trailing whitespace in my buffer. When I start a
> new indented line but end up not adding anything there, it highlights
> the region from the left of the to where the cursor was a trailing
> whitespace so I have a lot of ugly red blocks in my buffer. My new
> solution is not to highlight it, but to add a hook to emacs to delete
> it whenever I save my buffer.
> 
> (add-hook 'python-mode-hook
> (lambda ()
> 	 (add-hook 'local-write-file-hooks 'delete-trailing-whitespace)
> 	 ))
> 
> Now I can be blissfully unaware of trailing whitespace as before, and
> my editor will clean it out on save.
John,
Excellent! I always thought that something like this should be the 
solution--and should be a standard part of python mode (and of other 
language-specific modes)--but not being an emacs user, I did not know 
how to do it.
I assume there is also some sort of C and/or C++ mode, and similar hook 
additions are needed for them--correct? Or is there a hierarchy of 
modes, in which case a single hook could go at a higher level?
Eric

For those using emacs-22.1 (apparently local-write-file-hooks is 
deprecated and didn't work for me) --->
(setq python-mode-hook
 '(lambda ()
 (add-hook 'write-file-functions 'delete-trailing-whitespace)
))
Maybe we should do a big trailing whitespace removal en masse once we 
move the transforms branch to trunk to get this taken care of once and 
for all... (?)
Cheers,
Mike
John Hunter wrote:
> On Nov 21, 2007 1:52 PM, Andrew Straw <str...@as...> wrote:
>> Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
>> Looks like I'll now have to find a way to do the one thing in emacs that
>> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
> 
> I think I may have found the ultimate emacs solution. It really
> annoys me to see the trailing whitespace in my buffer. When I start a
> new indented line but end up not adding anything there, it highlights
> the region from the left of the to where the cursor was a trailing
> whitespace so I have a lot of ugly red blocks in my buffer. My new
> solution is not to highlight it, but to add a hook to emacs to delete
> it whenever I save my buffer.
> 
> (add-hook 'python-mode-hook
> (lambda ()
> 	 (add-hook 'local-write-file-hooks 'delete-trailing-whitespace)
> 	 ))
> 
> Now I can be blissfully unaware of trailing whitespace as before, and
> my editor will clean it out on save.
> 
> JDH
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> 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

On Nov 21, 2007 1:52 PM, Andrew Straw <str...@as...> wrote:
> Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
> Looks like I'll now have to find a way to do the one thing in emacs that
> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
I think I may have found the ultimate emacs solution. It really
annoys me to see the trailing whitespace in my buffer. When I start a
new indented line but end up not adding anything there, it highlights
the region from the left of the to where the cursor was a trailing
whitespace so I have a lot of ugly red blocks in my buffer. My new
solution is not to highlight it, but to add a hook to emacs to delete
it whenever I save my buffer.
(add-hook 'python-mode-hook
 (lambda ()
	 (add-hook 'local-write-file-hooks 'delete-trailing-whitespace)
	 ))
Now I can be blissfully unaware of trailing whitespace as before, and
my editor will clean it out on save.
JDH

My 1 year old only let me get the source release pushed last night and
build the mac release. I'll try to get the windows builds posted
tonight.
On Nov 28, 2007 8:23 AM, Rob Hetland <he...@ta...> wrote:
>
> On Nov 28, 2007, at 12:03 AM, John Hunter wrote:
>
>
> > I think native tcl/tk is preferable, but this is not a terribly
> > informed opinion. If you don't hear otherwise from someone else, just
> > build under that assumption.
>
> I am still having issues with Tk on my machine (native? version
> 8.4.7). In particular, event.key does not register (which I use
> quite a bit in my interactive grid generation tools). Not even the
> 'g' to toggle the grid. I also get an error when creating a figure
> instance:
>
> 2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool():
> Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased
> with no pool in place - just leaking
> <matplotlib.figure.Figure instance at 0x711300>
>
> Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the
> latest svn.
>
> I don't think anyone else is experiencing this problem. I reported
> it earlier, and John said it works fine for him -- nobody else chimed
> in to say they had the same problem...
>
> I just wanted to be sure you all were aware of potential Tk problems
> before your release.
>
> -Rob
>
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
>
>
>

On Nov 28, 2007, at 12:03 AM, John Hunter wrote:
> I think native tcl/tk is preferable, but this is not a terribly
> informed opinion. If you don't hear otherwise from someone else, just
> build under that assumption.
I am still having issues with Tk on my machine (native? version 
8.4.7). In particular, event.key does not register (which I use 
quite a bit in my interactive grid generation tools). Not even the 
'g' to toggle the grid. I also get an error when creating a figure 
instance:
2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool(): 
Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased 
with no pool in place - just leaking
 <matplotlib.figure.Figure instance at 0x711300>
Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the 
latest svn.
I don't think anyone else is experiencing this problem. I reported 
it earlier, and John said it works fine for him -- nobody else chimed 
in to say they had the same problem...
I just wanted to be sure you all were aware of potential Tk problems 
before your release.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Russell E Owen wrote:
> P.S. Chris: I've been meaning to ask you. Regarding my instructions for 
> building matplotlib: 
> <http://www.astro.washington.edu/rowen/BuildingMatplotlibForMac.html>
> is it still necessary to fuss with WX_CONFIG environment variable or is 
> that no longer needed for modern versions of wxPython and matplotlib?
yup -- as of wxPython2.8 -- we can do MPL in pure python. It will work 
with older version with, perhaps, a little less performance.
It's nice to get rid of that binary compatibility issue.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Before I push the OSX binary to SF I have 2 questions.
1. I used to be able to rename the file from "i386" to "fat" and have
it install on a ppc or intel machine. This doesn't seem to work
anymore even though this is a fat build. Any clues on how to approach
this?
2. Can anyone test this on 10.4? This brings up a similar naming
issue. Will 10.5 detect and install 10.4 labeled eggs from SF?
http://dev.imamuseum.org/~cmoad/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg
- Charlie

Charlie Moad wrote:
> - 0.91
> - numpy only
> - no wx compiled in (since 2.8 is pure python)
> - should tk use the default OSX installation for leopard?
> 10.5 comes with a working freetype, but I was still going to
> statically link it in for 10.4 users. It will be a FAT build.
sounds good to me.
I'm +0 on the Tk issue -- I don't use it. I think it may have been 
Russell Owen that had issues with Tk -- I've forwarded a note to him, so 
he can comment if he wants to.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...