On 10/03/2012 05:08 PM, Christoph Gohlke wrote: > On 10/3/2012 9:20 AM, Michael Droettboom wrote: >> I invite comments for a new MEP about improving the situation with >> respect to our bundling of third-party Python dependencies. >> >> In particular, I'd love feedback from the various stakeholders -- those >> producing binary installers and packages for the various platforms. >> >> https://github.com/matplotlib/matplotlib/wiki/MEP11 >> >> Mike > Hi, > > could dateutil, pytz, and pyparsing be made optional dependencies? I > just tried, all of my own scripts do work without them being installed > (one line needed to be removed in axes.py > https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes.py#L19). > Only about 10 of matplotlib's examples fail (after some additional > changes).
I think that sort of unbundling is a good idea to do in any case. Would you mind filing a PR with the changes you made? I think we still have to provide some sort of a hand-holding way to help people get dateutil/pytz/pyparsing etc. installed because if we take those features away people will complain. > > Frankly, I would remove/unbundle all 3rd party Python packages from > matplotlib and declare them as dependencies for pip and easy_install, > and of course in the documentation. If we can determine through experimentation that that's a reliable and convenient approach, that's what I would prefer. Binary installers make things more complicated. I'd prefer to have the installer automatically download the dependencies there, too, if we can work through the technical obstacles. > > I think that matplotlib, the library, should not attempt to work around > Python's distribution/packaging limitations. Please do not use > post-install or run-time scripts to detect and install missing > dependencies. Certainly -- but I don't want to provide people who are used to getting those dependencies from the installer to suddenly have a lesser experience. If some standard tool gives us what we need, great, otherwise we are going to have to make something that works. (All this is conjecture, because I haven't yet experimented with pip inside a Windows installer etc.) > > Concerning end user experience, the scipy-stack project seems like a > better place to address this. I agree -- but I think that's still a ways off. Also, remember there are a number of non-scientific users of matplotlib (data center monitoring is one such application I'm aware of) and those folks may be wary of installing a large scientific stack. Of course, perhaps that crowd is already using a proper package manager. > > Optionally, for Windows users that won't touch pip or easy_install (like > me), matplotlib could provide separate downloads of installers for > dateutil, pytz, pyparsing, and six. They are trivial to create. That's not a bad idea. But telling people they need to run 5 installers where there used to be 1 may be a hard sell. Any way to build a "meta" installer? > > It is also easy to create EGGs or MSIs for matplotlib, which are > occasionally requested. I'm perhaps showing my ignorance here, but is there any "one best way" among those options? I'd rather have one obvious best approach. > > Also consider a separate package for the matplotlib tests, which would > include 35 MB of baseline images that are of little use to end users. I've been wondering about this myself. I think what we probably want there is a separate Python package (i.e. a separate setup.py script), that lives in the same repository. It's important to keep the test data and the code in sync and a separate repository would just add needless complication. But that would easily allow binary installers and tarballs to be built without the test data. I think I'll add this to the MEP as a related task. Mike > > Christoph > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
