On 05/29/2013 05:19 PM, Russell E. Owen wrote:
In article <51a64bcf.80...@stsci.edu>,
Michael Droettboom <md...@stsci.edu>
wrote:
I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
Once the binaries from Christoph and Russell have been uploaded, I'll
make a broader announcement to get some testing of this in advance of
the final release.
The tarball is available here:
https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3
.0rc1/matplotlib-1.3.0rc1.tar.gz
The documentation for this version is viewable here:
http://matplotlib.org/1.3.0
Thanks everyone for their hard work getting this out the door!
It looks like the ability to include pytz and other dependencies in
binary distributions has been removed?
It's really just that the matplotlib source no longer includes them.
Binaries can be built however we want them to be. Not knowing how the
.dmg is put together, is it possible to add pytz, dateutil, pyparsing
and six to the dmg during its creation?
Is this really what we want? In the past we always included them.
Excluding them certainly makes sense if using pip or a similar installer
that can handle dependencies, but that is not the case for binaries.
Right -- and we're not using pip (because we can't) to handle our C/C++
dependencies, many of which we continue to ship with matplotlib.
I guess we could serve the associated packages (pytz, dateutil and six),
or if they can be installed by pip, ask users to install those. But
users using binary installers may not even have pip available, so it's a
big initial hurdle.
I'd personally be happier reverting to the old system. Sorry if I missed
a discussion on this.
No worries. I'm certainly guilty of not always being able to keep up
with the firehose myself. This work was done as part of MEP11 (
https://github.com/matplotlib/matplotlib/wiki/MEP11)
<https://github.com/matplotlib/matplotlib/issues/2092>, and searching
the mailing list with "MEP11" as a key should help you find the rest of
the discussion. It was pretty unanimous to move to not including these
dependencies -- I certainly understand that different communities and
platforms have different expectations, though, and if we want to find a
way to include the dependencies in the Mac installer, I'm not opposed to
that, but I would like to find a way to do it that only affects that one
particular use case and not all the others (i.e. something external to
or at least optional within the current setup infrastructure).
Mike
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
