Thanks for doing this work @jenshnielsen .
I wonder if it is time to split this toolkit out of the core repository so that it can move forward at its own pace, with its own tests, without us having to worry about the storage overhead that having another set of unit test images is inevitably going to cause. What do other think?

@leejjoon will obviously want visibility of this PR.

Thanks again,

I'm generally in favor of moving out the toolkits to their own repositories. I think in general that's the right approach, and doing so is much easier under github than it was on Sourceforge/SVN. However, I wonder if some users will be inconvenienced by now needing to install multiple packages (and needing to tell their colleagues to do so). We should probably consider this case as part of MEP11 and find a way to easily install these toolkits, even on, e.g. Windows, where pip/easy_install may not be installed.

Also, do we want to do the same with mplot3d?

In the short term, I don't think this PR needs to be held up by that decision -- it's perfectly fine to merge this for now and separate the toolkit out later.

On Mon, Oct 22, 2012 at 10:00 AM, Michael Droettboom <
notifications@github.com> wrote:

I'm generally in favor of moving out the toolkits to their own
repositories. I think in general that's the right approach, and doing so is
much easier under github than it was on Sourceforge/SVN. However, I wonder
if some users will be inconvenienced by now needing to install multiple
packages (and needing to tell their colleagues to do so). We should
probably consider this case as part of MEP11 and find a way to easily
install these toolkits, even on, e.g. Windows, where pip/easy_install may
not be installed.

Also, do we want to do the same with mplot3d?

In the short term, I don't think this PR needs to be held up by that
decision -- it's perfectly fine to merge this for now and separate the
toolkit out later.

I am against moving these toolkits out of matplotlib. Instead, I think
efforts should be made to eventually work them into matplotlib core.
There were specific reasons for not having them in the core. In
particular, the incompleteness of mplot3d, and the incompatibilities of
axesgrid1 with some parts of the existing core. I don't see mplot3d having
a chance to reach that point until py3k becomes the minimum due to the
necessary changes to the transforms stack (I need required keywords,
IIRC). However, I wonder if the axesgrid1 module might be a lot closer to
this goal?

I wasn't very clear in my first post -- I think we're more in agreement than I let on.

I think that while these toolkits are experimental, it makes sense to try to keep them more independent, so it's easier to update them at a different rate than the matplotlib core. But the end game (ideally, at least for things that are general-purpose, unlike basemap which is much more domain-specific) is to merge them into the core. I see it as rather analogous to most of the newer modules in the Python standard library -- they begin life as their own independent projects with a much higher API-change rate than Python itself, but then once they've settled down and stabilized their API, they are considered for inclusion in the core.

But perhaps given that consensus is brewing around having a faster release cycle for matplotlib, keeping the toolkits where they are now does in fact make the most sense.

I have added some more tests of the axesgrid1 toolkit and updated the test documentation to reflect this.
Is there anything else that needs to be done before this can be merged?

Travis is still thinking these tests are fine, so merge?

The PR doesn't merge without conflict, so it would be good to rebase.

Ok, i'll try a rebase this WE.

In need of a rebase. I also wonder whether, given this is a mpl toolkit and does not modify any of the backend rendering processes, if we can just test pngs rather than all 3 formats...

In general though, 👍

Yes, 👍. wrt to @pelson's comment about file formats, I tend to agree unless there are any specific tests where cross-backend things are an issue. Keeping the dist size and test run times low is getting to be a real priority.

I agree with @pelson here. It would be nice to have this merged.

@jenshnielsen: Would you be willing to get this rebased in line with the current v1.3.x branch?

I will look into it today or tomorrow.

Closing this since there now is a rebase on the v1.3.x branch