... just wanted to report this problem.
At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
Has anyone seen this problem before? Is there a workaround?
best wishes
Volker Blum
That is just bad packaging. TeX is not a dependency, but optional. Heck, it isn’t even listed in the “Build Requirements” page: http://matplotlib.sourceforge.net/users/installing.html#build-requirements
Matplotlib can work just fine without TeX, you just wouldn’t be able to set usetex=True in some places.
Ben Root
···
On Mon, Nov 14, 2011 at 9:20 AM, Volker Blum <blum@…1602…> wrote:
… just wanted to report this problem.
At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
Has anyone seen this problem before? Is there a workaround?
best wishes
Volker Blum
Hi Volker,
I have installed matplotlib with Fink. I had a similar issue, because I didn't need to GTKAgg backend and didn't want to install all of the GTK+ packages that were required. I ended up making my own fink package called matplotlib-py27-nogtk by editing the matplotlib-py.info and matplotlib-py.patch files in my /sw/fink/10.6/unstable/main/finkinfo/sci directory, to remove the dependencies and turn off the GTK+ check in setup.py, respectively. I put the resulting files in /sw/fink/10.6/local/main/finkinfo. You could try something like that, although it's kind of messy.
There may also be a "virtual" fink package for TeX that doesn't install anything, but counts as a proxy for a previous installation. If this is true, it's a much better solution that what I did.
I hope this helps. If you need more info, I suspect that your question is actually better suited for the fink-users list.
Good luck,
Jeff
···
On Nov 14, 2011, at 10:20 AM, Volker Blum wrote:
... just wanted to report this problem.
At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
Has anyone seen this problem before? Is there a workaround?
best wishes
Volker Blum
Thanks for the (two!) fast answers on the list. So there is hope 
I'll take a look at the fink internals, I guess.
best wishes
Volker
···
On Nov 14, 2011, at 5:15 PM, Jeff Blackburne wrote:
On Nov 14, 2011, at 10:20 AM, Volker Blum wrote:
... just wanted to report this problem.
At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
Has anyone seen this problem before? Is there a workaround?
best wishes
Volker Blum
Hi Volker,
I have installed matplotlib with Fink. I had a similar issue, because I didn't need to GTKAgg backend and didn't want to install all of the GTK+ packages that were required. I ended up making my own fink package called matplotlib-py27-nogtk by editing the matplotlib-py.info and matplotlib-py.patch files in my /sw/fink/10.6/unstable/main/finkinfo/sci directory, to remove the dependencies and turn off the GTK+ check in setup.py, respectively. I put the resulting files in /sw/fink/10.6/local/main/finkinfo. You could try something like that, although it's kind of messy.
There may also be a "virtual" fink package for TeX that doesn't install anything, but counts as a proxy for a previous installation. If this is true, it's a much better solution that what I did.
I hope this helps. If you need more info, I suspect that your question is actually better suited for the fink-users list.
Good luck,
Jeff
Thanks for the (two!) fast answers on the list. So there is hope I'll take a look at the fink internals, I guess.
best wishes
Volker
having said that ... after trying the one piece of software that I need on another platform, here's what I get:
File "[...]", line 84, in <module>
length = norm(dot(rlatvec,end) - dot(rlatvec,start))
File "/usr/lib64/python2.6/site-packages/matplotlib/mlab.py", line 1998, in norm
raise NotImplementedError('Deprecated - see numpy.linalg.norm')
NotImplementedError: Deprecated - see numpy.linalg.norm
The script that I was trying to get to work worked fine on Ubuntu this summer. Where has "norm" gone? How can it have been deprecated? It looks like a matplotlib problem, hence I am asking here.
[I am also asking out of some curiosity - I am sure the problem can be fixed relatively easily, but what I am wondering is, am I looking at a problem that came with a new version of matplotlib, am I using too old a version of matplotlib?]
best wishes
Volker
···
On Nov 14, 2011, at 5:34 PM, Volker Blum wrote:
On Nov 14, 2011, at 5:15 PM, Jeff Blackburne wrote:
On Nov 14, 2011, at 10:20 AM, Volker Blum wrote:
... just wanted to report this problem.
At the heart of the issue is the decision to have too many dependencies in matplotlib (which is why I am posting here). That, although viewed as good style, leads to an installation process that is, ultimately, practically impossible - except by buying a prepackaged solution. (which is possible but probably not the original intention)
What ultimately thwarts my installation attempts is the dependency on TeX. While a good thing in principle, most packaging tools do not realize that there is already a working TeX distribution there from another source, and will only accept their own - which, in the case of debian/fink, can no longer be postinstalled. It appears that I would have to uninstall and reinstall my entire pre-existing setup just to get matplotlib to work.
Has anyone seen this problem before? Is there a workaround?
best wishes
Volker Blum
Hi Volker,
I have installed matplotlib with Fink. I had a similar issue, because I didn't need to GTKAgg backend and didn't want to install all of the GTK+ packages that were required. I ended up making my own fink package called matplotlib-py27-nogtk by editing the matplotlib-py.info and matplotlib-py.patch files in my /sw/fink/10.6/unstable/main/finkinfo/sci directory, to remove the dependencies and turn off the GTK+ check in setup.py, respectively. I put the resulting files in /sw/fink/10.6/local/main/finkinfo. You could try something like that, although it's kind of messy.
There may also be a "virtual" fink package for TeX that doesn't install anything, but counts as a proxy for a previous installation. If this is true, it's a much better solution that what I did.
I hope this helps. If you need more info, I suspect that your question is actually better suited for the fink-users list.
Good luck,
Jeff
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
Others are probably more suited for explaining the hows and whys of mlab.py, but I will give it a crack. mlab.py was originally made to help assist users transitioning from Matlab over to matplotlib. Some functions that were probably considered to be top-tier in Matlab had to be accessed in sub-modules in NumPy, or were only available in the scipy packages. mlab.py attempted to address that.
There is also the issue where we were attempting to bridge compatibility with the old Numerix package which did not have many of these things at all. Support for Numerix has long been deprecated and so the need for many of the functions in mlab.py has gone away. This is why we now refer to the equivalent numpy function in the deprecation messages.
In v1.1.0, the norm() function is completely removed and you will not even get a deprecation message at all. The easiest solution is to adapt your scripts to use the numpy equivalents as suggested in the messages.
Cheers!
Ben Root
···
On Tue, Nov 15, 2011 at 2:53 AM, Volker Blum <blum@…1602…> wrote:
On Nov 14, 2011, at 5:34 PM, Volker Blum wrote:
Thanks for the (two!) fast answers on the list. So there is hope I’ll take a look at the fink internals, I guess.
best wishes
Volker
having said that … after trying the one piece of software that I need on another platform, here’s what I get:
File “[…]”, line 84, in
length = norm(dot(rlatvec,end) - dot(rlatvec,start))
File “/usr/lib64/python2.6/site-packages/matplotlib/mlab.py”, line 1998, in norm
raise NotImplementedError('Deprecated - see numpy.linalg.norm')
NotImplementedError: Deprecated - see numpy.linalg.norm
The script that I was trying to get to work worked fine on Ubuntu this summer. Where has “norm” gone? How can it have been deprecated? It looks like a matplotlib problem, hence I am asking here.
[I am also asking out of some curiosity - I am sure the problem can be fixed relatively easily, but what I am wondering is, am I looking at a problem that came with a new version of matplotlib, am I using too old a version of matplotlib?]
best wishes
Volker
Hi Ben,
thanks for the answer, ... umm, but did the person making the change realize that such error messages are exposed to users who do not have any idea what python is.
I would plead(*) with anyone that functionality that is not harmful please not be deprecated like this. Scripts based on matplotlib, as software, will have a much longer life than that 1 year it took to deprecate this harmless function.
best wishes
Volker
(*) I know it's free software, and I have neither right nor desire to demand anything like this. Hence the "plead".
... problem is, all we can do is evaluate whether matplotlib is safe to base our own work on here for the long term. The simple fallout from such a deprecation can be fixed in our own internal repository, sure ... but this quite central script will remain broken from the point of view of our users for a long time.
···
On Nov 15, 2011, at 4:50 PM, Benjamin Root wrote:
Others are probably more suited for explaining the hows and whys of mlab.py, but I will give it a crack. mlab.py was originally made to help assist users transitioning from Matlab over to matplotlib. Some functions that were probably considered to be top-tier in Matlab had to be accessed in sub-modules in NumPy, or were only available in the scipy packages. mlab.py attempted to address that.
There is also the issue where we were attempting to bridge compatibility with the old Numerix package which did not have many of these things at all. Support for Numerix has long been deprecated and so the need for many of the functions in mlab.py has gone away. This is why we now refer to the equivalent numpy function in the deprecation messages.
In v1.1.0, the norm() function is completely removed and you will not even get a deprecation message at all. The easiest solution is to adapt your scripts to use the numpy equivalents as suggested in the messages.
Cheers!
Ben Root
Hi Ben,
thanks for the answer, ... umm, but did the person making the change
realize that such error messages are exposed to users who do not have
any idea what python is.
I would plead(*) with anyone that functionality that is not harmful
please not be deprecated like this. Scripts based on matplotlib, as
software, will have a much longer life than that 1 year it took to
deprecate this harmless function.
best wishes Volker
(*) I know it's free software, and I have neither right nor desire to
demand anything like this. Hence the "plead".
... problem is, all we can do is evaluate whether matplotlib is safe
to base our own work on here for the long term. The simple fallout
from such a deprecation can be fixed in our own internal repository,
sure ... but this quite central script will remain broken from the
point of view of our users for a long time.
Volker,
The simple answer to your question about safety is "no, if safety in the long term requires that the code you write now must work with any future version of mpl". This is true throughout the software ecosystem of interdependent libraries--even in non-free software. It is particularly applicable to organically evolving libraries like mpl. We want the evolution of mpl to be as comfortable for users as possible, balanced with the need to improve. This includes the need to remove functionality that is marginal, obsolete, or inappropriate. All code has a maintenance cost. In addition, marginal or redundant functionality has a cost to users: increased learning time and likely confusion for anyone working with the library.
Eric
Others are probably more suited for explaining the hows and whys of
mlab.py, but I will give it a crack. mlab.py was originally made
to help assist users transitioning from Matlab over to matplotlib.
Some functions that were probably considered to be top-tier in
Matlab had to be accessed in sub-modules in NumPy, or were only
available in the scipy packages. mlab.py attempted to address
that.
There is also the issue where we were attempting to bridge
compatibility with the old Numerix package which did not have many
of these things at all. Support for Numerix has long been
deprecated and so the need for many of the functions in mlab.py has
gone away. This is why we now refer to the equivalent numpy
function in the deprecation messages.
In v1.1.0, the norm() function is completely removed and you will
not even get a deprecation message at all. The easiest solution is
to adapt your scripts to use the numpy equivalents as suggested in
the messages.
Cheers! Ben Root
------------------------------------------------------------------------------
RSA(R) Conference 2012
···
On 11/15/2011 06:23 AM, Volker Blum wrote:
On Nov 15, 2011, at 4:50 PM, Benjamin Root wrote:
Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________ Matplotlib-users
mailing list Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options