matplotlib-devel Mailing List for matplotlib

On Wed, Oct 3, 2012 at 10:08 PM, Christoph Gohlke <cg...@uc...> 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
> 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.
I whole-heartedly agree here. There are package managers for this job.
I understand there are people less package-literate and, as you point
out below, the development team for each separate dependency can ship
a binary. Though I understand not all do this.
> 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.
> 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 agree here, too. I think most people who want to use the library
won't ever run or touch the tests. Heck, I only ever ran the tests
after I started contributing back to the community. Perhaps they
should be spawn off to a matplotlib-tests git submodule that Travis
can use for commit-checking.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Wed, Oct 3, 2012 at 2:08 PM, Christoph Gohlke <cg...@uc...> wrote:
A bunch of great stuff:
+1 all around
Another use-case is py2exe, py2app, and friends -- at the moment, you
pretty much have to include the whole dang MPL package to get things
to work. Cleaning up some of these dependencies could improve that.
-Chris
> 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).
>
> 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.
>
> 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.
>
> Concerning end user experience, the scipy-stack project seems like a
> better place to address this.
>
> 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.
>
> It is also easy to create EGGs or MSIs for matplotlib, which are
> occasionally requested.
>
> 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.
>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

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).
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.
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.
Concerning end user experience, the scipy-stack project seems like a 
better place to address this.
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.
It is also easy to create EGGs or MSIs for matplotlib, which are 
occasionally requested.
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.
Christoph

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

+1
On 10/03/2012 04:36 AM, Phil Elson wrote:
> Good question!
>
> It would certainly be a welcome deprecation from my point of view. 
> There is a fair amount of overhead maintaining it if you make any 
> changes to the way backends work (as I have done a couple of times 
> recently).
>
> Depending on feedback here, it is something we could potentially 
> deprecate in 1.2 and then completely remove by 1.3.
>
> Cheers,
>
>
>
>
> On 2 October 2012 20:13, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
> Is there any good reason to retain the original NavigationToolbar code
> in the backends, and the corresponding "classic" option in
> rcParams['toolbar']?
>
> Eric
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> <mailto:Mat...@li...>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Good question!
It would certainly be a welcome deprecation from my point of view. There is
a fair amount of overhead maintaining it if you make any changes to the way
backends work (as I have done a couple of times recently).
Depending on feedback here, it is something we could potentially deprecate
in 1.2 and then completely remove by 1.3.
Cheers,
On 2 October 2012 20:13, Eric Firing <ef...@ha...> wrote:
> Is there any good reason to retain the original NavigationToolbar code
> in the backends, and the corresponding "classic" option in
> rcParams['toolbar']?
>
> Eric
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>