Red Hat Bugzilla – Bug 502082
Recent version bump of python-numpy breaks python-matplotlib
Last modified: 2010-09-24 09:15:24 EDT
In EPEL5, python-numpy was recently bumped to numpy 1.2.1 . This is incompatible with matplotlib 0.90.1 , which is the latest python-matplotlib. Please bump the version to 0.91.2 or higher . All things being equal, newer is probably better.
 $ python
Python 2.4.3 (#1, Jan 21 2009, 01:11:33)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> print numpy.__version__
>>> import pylab
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib64/python2.4/site-packages/pylab.py", line 1, in ?
from matplotlib.pylab import *
File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line 199, in ?
File "/usr/lib64/python2.4/site-packages/matplotlib/cm.py", line 5, in ?
File "/usr/lib64/python2.4/site-packages/matplotlib/colors.py", line 38, in ?
from numerix import array, arange, take, put, Float, Int, putmask, \
File "/usr/lib64/python2.4/site-packages/matplotlib/numerix/__init__.py", line 154, in ?
__import__('ma', g, l)
File "/usr/lib64/python2.4/site-packages/matplotlib/numerix/ma/__init__.py", line 12, in ?
from numpy.core.ma import *
ImportError: No module named ma
bumnping matplotlib to anything newer comes at a cost of API breakage for any scripts making using of matplotlib routines.
As a matplotlib user would you rather have a patched matplotlib 0.90.1 which works with the new numpy or a a newer matplotlib which could break scripts in a number of different ways?
If I do a new version of matplotlib I'm just going to jump directly to what is shipping in Fedora 11. Once I introduce any API breakage via a version bump.. there's no reason to hold back.
I'm not exactly thrilled to see the newer numpy show up without being notified. But that's between me and the numpy package maintainer to discuss.
Sorry to cause trouble.
My collaboration appears to be happier with bumping matplotlib all the way. To the max. Debian Lenny, our other target platform, is at 0.98.1, which is close to to the head.
as another matplotlib user, I would also vote for bumping all the way to the newest available.
For some matplotlib using software I'm distributing, I think compatibility with current versions of other distros and operating systems is more important than keeping backward compatibility for EL5.
My second use case, using matplotlib for my own plotting scripts (a lot of them!) as well as interactive use via ipython, I would again prefer the new features and bugfixes in the newest version over backwards compatibility.
I apologize for being so impatient, but users have started to notice the breakage and ask me for workarounds. To determine the best course of action, it would be helpful to know how soon you intend to roll out a new version.
today... i should be able to push a build into the build system today. I hope.
Okay build pushed.
Package python-matplotlib enqueued. Job ID: 2391.
okay the build was successful.
Has the update shown up yet on the mirrors?
(In reply to comment #7)
> okay the build was successful.
> Has the update shown up yet on the mirrors?
The update showed up and it appears to work for our purposes. Thank you very much.
As an aside, it appears that the major API breakage for us is the numpy.histogram / pylab.hist issue.
Based on "The update showed up and it appears to work for our purposes. Thank you very much."
I'm closing off this bug