Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Michael D. <md...@st...>]

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel