ANN: matplotlib-1.3.0rc1

In article <51A64BCF.80803@...31...>,
Michael Droettboom <mdroe@...31...>
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:

matplotlib - Browse Files at SourceForge.net
.0rc1/matplotlib-1.3.0rc1.tar.gz

The documentation for this version is viewable here:

matplotlib: python plotting — Matplotlib 1.3.0 documentation

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?

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.

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.

-- Russell

If the binary installers are available (and easy to find), not such a
big deal -- this is teh case with Christoph's repository for Windows,
for instance.

Russell, have you been following the thread I started on the pythonmac
list? We really need a way to deal better with binaries on the Mac,
including dependency handling.

Note that supposedly the "wheel" format is coming (soon?), and after
that support for binary wheels by pip.

Of course, none of that helps right now...

-Chris

···

On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen <rowen@...748...> wrote:

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.

--

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

Chris.Barker@...236...

I have been following that thread with great interest. If such a repository becomes available I do intend to contribute to it.

For the record:
- I prefer static libraries
- The wheel format sounds very promising. But until we have it and until pip supports it, my suspicion is that it's not worth trying to automate dependency handling, and we should live with mpkg binary installers.

In the short term I'd be happier if matplotlib continued to support including dateutils, pytz and six. It is not ideal to include dependencies, but convenient and pragmatic. Failing that, i think we should ask users to install pip and use pip to install dateutils, pytz and six. I fear it would be too much work to provide binary installers for pytz, dateutils and six because we would need to make different packages for different versions of python (which feels silly for pure python packages!), keep them up to date, find somewhere to serve them...

In the long term, I hope wheel format will allow us to use pip to install matplotlib, in which case it will handle dependencies and we need not include them.

-- Russell

···

On May 29, 2013, at 4:01 PM, Chris Barker - NOAA Federal <chris.barker@...706...36...> wrote:

On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen <rowen@...748...> wrote:

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.

If the binary installers are available (and easy to find), not such a
big deal -- this is teh case with Christoph's repository for Windows,
for instance.

Russell, have you been following the thread I started on the pythonmac
list? We really need a way to deal better with binaries on the Mac,
including dependency handling.

Note that supposedly the "wheel" format is coming (soon?), and after
that support for binary wheels by pip.

Of course, none of that helps right now...

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?
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.
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 (

···

On 05/29/2013 05:19 PM, Russell E. Owen
wrote:

 In article ,
Michael Droettboom 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:
.0rc1/matplotlib-1.3.0rc1.tar.gz
The documentation for this version is viewable here:
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?
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.

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.

https://github.com/matplotlib/matplotlib/wiki/MEP11)

<51A64BCF.80803@…31…><mdroe@…31…>https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3http://matplotlib.org/1.3.0

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?

I agree -- adding them to the binary package is the way to go here --
it's packaging issue, not a development or building issue.

I can't imagine it would be hard to write a little script that
includes them all in one mpkg.

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.

Should the code that's shipped with MPL be build-able with PIP? But
the harder issue is third-party dependencies that we expect the system
to provide: libpng, libfreetype, ....

On the building side, I'd really like to see more support for this --
the Linux package managers handle it OK on LInux, but there is no good
system for Windows or OS-X.

I'm taking a look at gattai:

Mostly for the Mac, but it does support Windows and linux as well.

I'm not looking at Windows right now, as Christoph's repository gives
me all I need -- which makes me think:

Christoph, do you have a build system for all those that might be a
good basis for a multi-platform solution?

-Chris

···

On Wed, May 29, 2013 at 5:54 PM, Michael Droettboom <mdroe@...31...> wrote:

--

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

Chris.Barker@...236...