... note that horizontal colorbars don't suffer from this problem so nothing was changed for XAxis....

... moved to draft. cb.ax.set_title has the sae problem (though that usage is more rare, I expect)

Power-cycled now that we have fixed CI

Yes it does look relevant. Are you trying to get 3.5.2 out the door? I'm away from my computer until next wed (16 feb). Looks like the check for outline in the colorbar spine dict is not correct.

No, not yet, probably next week.

I can fix the 17th or so, but not before. If anyone wants to push a check to the PR it's not a problem. Thanks!

OK, I admit to being quite stymied by the doc failure. What is happening is that the quick_start code is somehow creating a second figure in the pyplot registry, and this second figure is not quite setup properly. You can check this by adding print statements to thematplotlib_scraper in sphinx_gallery and seeing that it tries to create two figures for this part of the example.

The root of the problem seems to be the deepcopy innorm:

If I remove this, then the sphinx scraper doesn't create the extra figure.

Thedeepcopy arose because of the extra state that@greglucas added to sync colorbars and mappables. The failure is on norms made with_make_norm_from_scale which@anntzer added. If I manually defineNorm to have a__deepcopy__ that simply returns the copy, then the failure goes away. I'm hoping either@greglucas or@anntzer can take a look and help us figure out what the heck is going on.

Looking at the code here, it definitely somehow triggers this weirdness, but I'm not understandingwhy it should.

The reproducer here is to put print statements insphinx_gallery/scrapers.py in the matplotlib scraper, and see that print(plt.get_fignums()) returns two figures for "Color mapped data" inquick_start.py:

Strange indeed... This looks like it is also not working correctly on the current docs build on main, although not failing.
https://67051-1385122-gh.circle-artifacts.com/0/doc/build/html/tutorials/introductory/quick_start.html?highlight=quick%20start#color-mapped-data

So, I don't think this PR is a culprit, just hitting a louder failure. I'll try and dig deeper this evening if@anntzer doesn't figure it out before that.

Ah, good catch. Yes, this PR is probably squeaking because the spine is squished to nothing in the weird second figure.

Again, it has something to do with the deepcopy in colorbar. If I remove that it seems to work fine. But the deepcopy has been around for a while, so I suspect some of the recent changes to the norms.

I probably won't have the time to investigate this for a few days, sorry. I'll try to get back to it later...

A fix to remove the deepcopy is in#22523, which solves the docs build here, but does not solve the underlying problem that could crop up somewhere else.

The root cause bisects to:#21597
So, definitely something going on with the deepcopy on transforms. Removing getstate/setstate also makes the example "work" again, but of course causes other issues with pickling. So something with expanding the weakrefs of the parents attribute I think. We could revert that deepcopy removal commit and lose the ability to copy figures as possibly the easiest solution if we hit other issues here.

#22523 will fix the doc build for the main branch with this PR, and this shouldn't be an issue on 3.5 as the failing code was introduced after the 3.5.x branched off. I've re-opened a separate issue to track the underlying issue here which is the picklability of norms:#20755

#22523 is in.@jklymak please rebase to see that the doc build is fixed with that.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.5.xgit pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -m1 698397f95b61d007137ead5e733f6a1b1ecff032

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #22313: Fix colorbar exponents'

4. Push to a named branch:

git push YOURFORK v3.5.x:auto-backport-of-pr-22313-on-v3.5.x

5. Create a PR against branch v3.5.x, I would have named this PR:

"Backport PR#22313 on branch v3.5.x (Fix colorbar exponents)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove theStill Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free tosuggest an improvement.

@jklymak@greglucas Sorry I didn't have the time to look at this; I'm trying to catch up a bit now. If I understand correctly there may still be a bug wrt deepcopying norms made with make_norm_from_scale? (which#22523 works around, but may otherwise may still be present?) Do colorbars need to be involved at all? Do you have a repro I can look at? (other than reverting#22523, as that PR seems like a good idea to me regardless)

Yes, they are still broken and you actually had a patch :) You can add this to the current test:
#20755 (comment)

I also was curious on whether this would be one of the cases where a metaclass might help as being a kind of class factory here, but I didn't think about that too much.