matplotlib-devel Mailing List for matplotlib

On Fri, Oct 7, 2011 at 21:55, Fernando Perez <fpe...@gm...> wrote:
> On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben...@ou...> wrote:
>> That's valid. I guess I am just wondering if there is a decent error
>> message to the user explaining that the test could not proceed.
>
> Rig the test runner to properly skip them instead of failing? The
> test data should be considered a dependency for those tests, and
> absent the dependency, the users simply get less tests, but not a ton
> of failures.
>
> Not saying this should be done *now*,
+1
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Mac binaries for Python 2.6 and 32-bit Python 2.7 are now uploaded.
-- Russell
On Oct 6, 2011, at 8:18 AM, John Hunter wrote:
> On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jd...@gm...> wrote:
> ...
> Actually, if you can just upload the binaries directly to
> 
> https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/
> 
> that will save a step...

Oops. Sorry about that.
1.1.0 built fine under Python 2.7 and passes all tests (except one known skip).
I'll build 2.6 next and then upload both.
-- Russell
On Oct 7, 2011, at 12:11 PM, Benjamin Root wrote:
> This build you are doing is v1.0.1, which is the old version. Did you grab the wrong source, or did we upload the wrong stuff?

On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben...@ou...> wrote:
> That's valid. I guess I am just wondering if there is a decent error
> message to the user explaining that the test could not proceed.
Rig the test runner to properly skip them instead of failing? The
test data should be considered a dependency for those tests, and
absent the dependency, the users simply get less tests, but not a ton
of failures.
Not saying this should be done *now*, but I think in general having
users be able to run the test suite in their environments is useful,
even if parts are skipped for some reason. You never know when that
will uncover true failures...
That's the approach we take in ipython: we have a lot of tests that
depend on various tools/environment/os, that simply get skipped. In
fact, there is no way to run the *entire* ipython test suite in one
go, since there are mutually exclusive tests (like things that only
run on OSX or Windows). So inevitably, every test run is *always*
partial. Once you think about it that way, then this is just one more
dependency to be handled just like any other.
Cheers,
f

On Fri, Oct 7, 2011 at 1:50 PM, Russell E. Owen <ro...@uw...> wrote:
> I'm running into an error building the Mac binary:
>
> d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$
> bdist_mpkg
> basedirlist is: ['/usr/local']
> =========================================================================
> ===
> BUILDING MATPLOTLIB
> matplotlib: 1.0.1
> python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011,
> 14:13:39)
> [GCC 4.0.1 (Apple Inc. build 5493)]
> platform: darwin
>
> REQUIRED DEPENDENCIES
> numpy: 1.6.1
> freetype2: found, but unknown version (no pkg-config)
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line
> 8, in <module>
> load_entry_point('bdist-mpkg==0.4.4', 'console_scripts',
> 'bdist_mpkg')()
> File
> "build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line
> 27, in main
> File "setup.py", line 162, in <module>
> if check_for_tk() or (options['build_tkagg'] is True):
> File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line
> 832, in check_for_tk
> (Tkinter.__version__.split()[-2], Tkinter.TkVersion,
> Tkinter.TclVersion))
> IndexError: list index out of range
>
> I have ActiveState Tk installed. Tkinter reports the following values:
> Tkinter.__version__ = "$Revision$"
> Tkinter.TkVersion = "8.4"
> Tkinter.TclVersion = "8.4"
>
> I assume I can get past this by hacking up setupext.py; I'm willing to
> do that, but I'm wondering if it makes more sense to fix the bug. How
> many other users are going to be bit by this?
>
> 1.0.1rc1 built with no problems, but I see that setupext.py had some
> revisions since then.
>
> -- Russell
>
> P.S. I have no idea why freetype2 and libpng install without pkg-config;
> I install them in in /usr/local in the usual way. However, those
> warnings have been present for a long time and it never seems to cause
> any trouble.
>
>
This build you are doing is v1.0.1, which is the old version. Did you grab
the wrong source, or did we upload the wrong stuff?
Ben Root

I'm running into an error building the Mac binary:
d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$ 
bdist_mpkg
basedirlist is: ['/usr/local']
=========================================================================
===
BUILDING MATPLOTLIB
 matplotlib: 1.0.1
 python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 
14:13:39)
 [GCC 4.0.1 (Apple Inc. build 5493)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.6.1
 freetype2: found, but unknown version (no pkg-config)
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line 
8, in <module>
 load_entry_point('bdist-mpkg==0.4.4', 'console_scripts', 
'bdist_mpkg')()
 File 
"build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line 
27, in main
 File "setup.py", line 162, in <module>
 if check_for_tk() or (options['build_tkagg'] is True):
 File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line 
832, in check_for_tk
 (Tkinter.__version__.split()[-2], Tkinter.TkVersion, 
Tkinter.TclVersion))
IndexError: list index out of range
I have ActiveState Tk installed. Tkinter reports the following values:
Tkinter.__version__ = "$Revision$"
Tkinter.TkVersion = "8.4"
Tkinter.TclVersion = "8.4"
I assume I can get past this by hacking up setupext.py; I'm willing to 
do that, but I'm wondering if it makes more sense to fix the bug. How 
many other users are going to be bit by this?
1.0.1rc1 built with no problems, but I see that setupext.py had some 
revisions since then.
-- Russell
P.S. I have no idea why freetype2 and libpng install without pkg-config; 
I install them in in /usr/local in the usual way. However, those 
warnings have been present for a long time and it never seems to cause 
any trouble.