Just done a bit of research about this, python changed the values on this so -1 in python2.x means 0 in python3, grr. As this gives default behaviour, I think we can just remove the -1 altogether.

As I make some changes around that line in MEP2 (#4143), I would prefer to make that change there (I want to keep rebasing to a minimum), plus I would like to add something to Travis to get it to run separate builds on the 2.7 and 3.4 with rcParam['toolbar'] = 'toolmanager'. Not quite sure how to do that though. @jenshnielsen do know of a way? At the moment I have just left off the rcParam, waiting until the final moment before merging to add it, but not the best method 😉.

So do you mind just making this change locally for now?

@OceanWolf At the top of the .travis.yml file we define a bunch of environments. 2.6 ... 3.4, pep8 and docs. They are all something like:

 - python: 2.7
     env: TEST_ARGS=--pep8

The first line of cause defines the python version and the second one defines which env variables to set:

So you likely want to add something like:

 - python: 3.4
     env: USENEWTOOLMANAGER=true

and then add something to the main script along the lines of

if [[ $USENEWTOOLMANAGER == true ]]; then
    do something to enable the new tool manager
fi

just before the running the tests.

Just let me know if this doesn't make sense or you need more info. I really should refactor the travis file to make it a bit more manageable. At this stage it is gigantic script with everything on top of each other.

Ahh, okay, thanks... by "main script" I presume you mean in the if __name__ == '__main__': part of matplotlib/tests.py?

No sorry, I meant the part of the .travis.yml file that starts with script:

One of our current testing issues it that we have to many entry points to running the tests.

At this stage we have:

• python tests.py
• python setup.py test
• from python: matplotlib.test()

and they all have different code paths at some stage so if it is possible to only modify the travis.yml file,
by something like having it create a matplotlib rc file enabling the new toolbar, I think that is simpler

Ahh, just pushed, I will make an edit to this effect. Do I need to do any tear down on travis? I.e. removing the file? Or does that happen automatically?

Yes the changes happens automatically. If you want it on multiple branches we need to merge to master to have other branches build. When you push a new commit Travis will automatically rerun but it will not kill the old job so the wait time will go up if you push often and you should be able to kill no longer relevant jobs by clicking on them in the interface.

Ahh, mixup, I meant I had already pushed the bad way to Travis.

With me asking whether travis auto-removed the file I referred to removing a .config/matplotlib/matplotlibrc file, or whether I would have to remove that file manually afterwards...

Ok no problem

There is no need to do a teardown step and remove files unless you want to do something afterwards. Every Travis job starts with a fresh VM image which we install stuff into and unless we actually store something by pushing to github, uploading to AWS or whatever files we create are thrown away. That is why we have a upload test images to aws step in there.

I don't understand, no test errors on #4143 what do I do wrong?

python changed the values on this so -1 in python2.x means 0 in python3, grr

No, 0 always meant absolute import; -1 was "the default", which was probably relative given it was Python 2. I'm not sure as the docs are not clear.

As this gives default behaviour, I think we can just remove the -1 altogether.

That would give inconsistent behaviour between 2 and 3. If you want to use 0, then you'd need to add 'matplotlib.' to the beginning of the module name.

As I make some changes around that line in MEP2 (#4143), I would prefer to make that change there (I want to keep rebasing to a minimum),

OK, I wasn't sure if that was targetted at 1.5 or not.

This should be fixed for 1.5.

Damn, I had hoped to see this as an error in Travis in #4143 once #4810 had entered master... 😞.

@OceanWolf Sorry, I am confused.

I would like to have this out the door with 1.5, where as I am on the fence about about #4810 going in for 1.5 and against #4143 going in for 1.5.

@tacaswell To explain my comment above, #4810 adds pgi and allows us to, and so we do test the GTK3 backend on Travis. In #4143 I add extra travis builds to test the new toolbar rcParam and thus Travis should catch this bug in the new toolbar there. I had hoped to use this as a test that the new tests work, but it doesn't really matter.

I have said many times that the new toolbar should not make 1.5 unless #4143 does, but I have had no response whenever I have said this. The reasons for this:

1. MEP27 Decouple pyplot from backends (refactoring Gcf out of backend code) #4143 makes SIX of the new Tool classes obsolete (two base + two per backend), and thus spreading the new toolbar and the new window between a year's release makes it more troublesome as these "new" classes will have to go through a deprecation cycle.
2. Without MEP27 Decouple pyplot from backends (refactoring Gcf out of backend code) #4143 We have to release ToolQuit with dirty Gcf logic and then we have to keep it so as to deprecate the old window system safely, thus requiring us further dirtying ToolQuit in MEP27 Decouple pyplot from backends (refactoring Gcf out of backend code) #4143 to add detection as to whether we use the old or the new window code.
3. By releasing the new toolbar and the new window separately we have to use different rcParams for them, me and @fariza already had a long discussion about this over in rcParams for MEP27 OceanWolf/matplotlib#4. Perhaps though two rcParams works better.

@tacaswell is there any specific reasons to be against #4143 in 1.5?

@OceanWolf I agree with you that it would be better to have #4143

But I have to disagree on removing ToolManager, it is not that with #4143 those tools are going to disappear, they are going to be revamped, they are going to still exist for every backend, and with the same name. The implementation is going to change, but the functionality is going to be the same.

I am against putting #4143 in for 1.5 because I wanted to have an RC out a week ago and I am making a judgment call on what to prioritize for this release. That PR is changing/replacing a lot of very important code, that is not something we want to force in under a deadline.

I thought the new toolbar was only implemented for Gtk and is puerly opt-in. I am fine with marking it 'experimental' and not doing a full deprecation cycle for any of those classes. To know to opt-in users have to be told about it and we can do so with enough warnings it will be ok. I think that is less effort than ripping the new toolbar out for the release and then putting it back in and we will get feed back from some users.

The goal is 2.1 around April so it should not be a full year before the next release.

@tacaswell Okay, marking it as experimental/alpha sounds good to me with warnings stating it as such... and that the API will most likely change in 2.1 (best to over-dramatize it, then understate it, so people really know), and yes, I know, 0.75 years, I rounded it to 1 😈.

@fariza What do you mean by "removing ToolManager"? I didn't mention that class, MEP27 removes the following classes from master... ConfigureSubplotsBase, SaveFigureBase, ConfigureSubplotsTk, SaveFigureTk, SaveFigureGTK3, and ConfigureSubplotsGTK3. The first two I replace with non-base versions; the last two I remove in #4143, the others I will remove in the Tk PR of MEP27.

@tacaswell I agree with you, it's opt-in, so users know there is something different there.

@OceanWolf What I meant is that you wanted MEP22 removed for this release. And for the classes, of course ConfigureSubplotsGTK3 and ConfigureSubplotsBase are going to be removed but the final exposed class ConfigureSubplots still there with the same functionality. The users are not supposed to use those intermediary classes anyway.... some might do