Workarounds

[rcomer]

Suppose we put a workaround in Iris to handle a bug in one of its dependencies. For example

iris/lib/iris/plot.py

Lines 1276 to 1280 in 83309c3

	# set the _is_stroked property to get a single color grid.
	# See https://github.com/matplotlib/matplotlib/issues/1302
	result._is_stroked = False
	if hasattr(result, "_wrapped_collection_fix"):
	result._wrapped_collection_fix._is_stroked = False

If the bug is fixed some time later, do we have a policy for removing the workaround, in particular how soon to do that? This particular bug appears to have been fixed at mpl 3.4.1 (see #4090). I guess it may not be fair to assume that every user of Iris 3.1 will have the latest mpl version, as it could be pinned in other packages they are using. So how long is it reasonable to wait?

[bjlittle]

@rcomer I suggest that you remove the workaround and we can pin to a minimum version of i.e., mpl>=3.4.1

That seem completely reasonable to me to have a minimum bar for dependencies... otherwise workarounds would never be removed from the codebase.

Go for it. If you make a PR, I'd merge it 👍

[tkknight]

I have an IEP (Iris Enhancement Proposal) drafted (no PR yet). I think an IEP for stating our intent on supporting the more recent Python versions would be a way to go.

[bjlittle]

@tkknight Nudge acknowledged... let's get that IEP infra-structure up and running ❤️

[rcomer]

I'm kinda nervous about the idea of pinning matplotlib to the latest version. There are a lot of packages out there that interface with mpl, and some may have it pinned to older versions (indeed Iris was in that position till only last summer). So wouldn't we risk creating conflicts so a user just can't create an environment with the combination of packages they want?

If we remove the workaround and don't pin, the worst that could happen is unexpected results with one specific iplt function.

[rcomer]

So I finally opened that PR #4999

[trexfeathers]

Is there anything to discuss about how we keep track of such workarounds? There must be a few such things scattered throughout the source code that we have lost awareness of, but maybe that's OK if they're not causing any harm?

[rcomer]

We have a test that failed once this particular matplotlib bug was fixed. I wonder if whoever put the test in did so as a reminder to remove the workaround later? Although there wasn't a comment to say so.

iris/lib/iris/tests/test_mapping.py

Lines 241 to 244 in 83309c3

	def test_grid(self):
	iplt.pcolormesh(self.cube, facecolors="none", edgecolors="blue")
	# the result is a graphic which has coloured edges. This is a mpl bug,
	# see https://github.com/matplotlib/matplotlib/issues/1302

Your question is pertinent to #3790, since I'm proposing a numpy workaround there.

[rcomer]

Aside: the PR that added the mpl workaround also added the "swanky new idiff tool" 😆 #109

[trexfeathers]

That seems like a good 'self-organising' pattern.

[rcomer]

I wonder if whoever put the test in did so as a reminder to remove the workaround later

Hmmm probably not actually, as the test was already there, but modified when the workaround was added.
https://github.com/SciTools/iris/pull/109/files#diff-bdbebdfefdcd1f50d7bd045ebf303f65181b7e6534e98c575e907882c78e8e2f

[pp-mo]

Discussed again in peloton ..
Perhaps we can label these "TODO:" along with other issues
--> entry to review these in the release checklist ??