matplotlib 1.3.1 is broken on windows #2773
Comments
|
matplotlib stopped bundling If you have |
|
That is unfortunate. I use matplotlib in my computational physics class and this is significantly less user friendly for my students who use windows. There doesn’t seem to be any official dateutil package that can be double clicked to install. My students don’t generally know what to do with a .tar.gz file and for the last five years they haven’t needed to know to use matplotlib. This seems like a regression in terms of user friendliness. Once I install dateutil using an unofficial package then I get an error about pyparsing. I also don’t see anything in the installation instructions at http://matplotlib.org/users/installing.html about needing dateutil and pyparsing for Windows. In fact it specifically says Windows users only need to install python and numpy to use matplotlib. I’m rather puzzled by this step backwards in terms of ease of use for matplotlib on Windows. Dr. James P. Clemens On Jan 29, 2014, at 3:50 PM, Thomas A Caswell notifications@github.com wrote:
|
|
irrc, pyparsing was pulled out of our source tree at the same time (see #1290 for discussion). Are you aware of Chris Gohlke's (http://www.lfd.uci.edu/~gohlke/pythonlibs/) pre-built binaries? There are also build of both modules on pypi. If you are using windows I would suggest using either enthought's or continioum.io's pre-built bundles which in my experience have 'just worked'. I will get a patch in tonight to update the documentation, it looks like that slipped by when the change was made. |
|
I am aware of Chris Gohlke’s binaries but they are labeled “unofficial” and it is not ideal to ask students to install packages from a random website. I prefer to send them directly to the source website for the packages so that they learn where they are and how to install the appropriate software. I also prefer not to ask Windows users to go to the command line to install software. It appears that is the preferred method for installing packages from PyPI. One of the things I try to emphasize in the class is the usefulness of open source software and that once students have learned these tools they will always have access to them as they progress through their career. If Windows (or Mac) users have to go to the command line the software does not feel accessible to them. It undermines the idea that they will always be able to find these tools and install them wherever they are working. Similarly, pointing them to a prebuilt bundle like Enthought or Continuum which appears to be semi-commercial also undermines the idea of open source tools being always available. I have had great success using Python, Numpy, scipy, matplotlib, and VPython over the last five years as a teaching tool and I’m just disappointed that a stumbling block has unexpectedly appeared this year. For this semester I will revert to matplotlib 1.2.1 and I’ll have to decide what to do in the future. In any case, thanks for your help. Dr. James P. Clemens On Jan 29, 2014, at 4:27 PM, Thomas A Caswell notifications@github.com wrote:
|
|
I totally agree with clemenj2. I highly admire the hard work of maintainers, but this is an extremely wrong move. The more you depend on external stuffs, the more difficult the maintenance and installation tend to be. Why do we have to google and locate for this and that (rather uncommon, tiny) packages, just for fresh, clean, standard installation? Are you really sure that it's a good idea to tell someone who just want to start a little python & plotting job, like this: "Okay, don't install the official python. Instead, get this (huge) Enthought. Or do PyPI. You don't know PyPI? Google it. Or google for dateutil. Still got errors? Then google for..." Come on, it's 2014 and not the MS-DOS era. BTW, after 3 months, the web page (http://matplotlib.org/users/installing.html) is not corrected, and still misleadingly says: "Windows users only need the first two (python and numpy) since the others are built into the matplotlib Windows installers available for download at the download page https://github.com/matplotlib/matplotlib/downloads_. " This fact already proves that it is hard to maintain consistency over package dependency. :-) I also think that counting exclusively on other packages/systems (Enthought, PyPI, etc) is risky and should be avoided whenever possible; the more maintainers, the more bugs, the harder your tracking down will be, once something goes wrong. CHeeeeeeers |
|
@ohyeahq Including an independent package causes far more headaches (as now you can end up with multiple versions of the module in your path and it is a bit of a toss up between systems which one gets used which can break other module and introduce bugs that depend on the import order of various modules) and it annoys the down-stream packagers (linux distributions, enthought, continium.io, etc). I am sorry to hear you are having problems, but I do not think this will be reverted. The docs have not been regenerated, but that language has been changed in the source and will be correct for 1.4 |
|
Thank you for your quick reply. I do understand there is a good reason for you for this externalization. My point is that there are more disadvantages to many users, and ultimately, to maintainers. The idea that PyPI (or Enthought etc) would keep everything consistent is an illusion. The reality can easily be seen in those flooding bug trackers. Maintainers are great people; but they are cutting-edge experts, and their nature is in experiments and development, not in boring bug fixes. As a result, the 'improvement' constantly carries bugs in. (Look at openssl.) PyPI itself, such an admirably well-received system, is not robust or reliable. It depends on pip, which depends on either setuptools (which had already been abandoned in 2012) or distribute (which had a security issue). If matplotlib (non-essentially) depends on A, and A depends on B, and B on C, what happens if C gets flawed? We cannot fix it because it's external; we have to wait for its maintainers to react to it. In half a year or so? Maybe, but we need this nice plot by tomorrow! :-) OK, let's fix it quick'n dirty for now on our side. But, after some months -- when we forget all about it -- the package C suddenly gets updated with a totally different, conflicting fix (and we don't even notice it). Well, sorry, I almost remind myself of my own past nightmare. Here are my suggestions. (1) If package A is small, non-essential, and mature, make a fork for a matplotlib specific version. Rename it to avoid conflict. Or: Maintainers should be proud of matplotlib, THE STANDARD for python computing. And because of that, the critical updating of the installation guide is a matter of a day or two, not of months. Way too many people have been affected negatively in the past 3 months. Cheeeeeers :-) |
|
@ohyeahq and @clemenj2 are right: this is a serious mess. Installation is an Achilles heel even with good documentation, and our documentation of it is way out of date. (See the FAQ entry.) |
With a fresh install of python 2.7.6, numpy 1.8.0, and scipy 0.13.2, matplotlib 1.3.1 fails when I try to import pylab, complaining that it requires dateutil. As far as I know I have installed everything just as I have in the past when matplotlib worked without any issues.
The text was updated successfully, but these errors were encountered: