fix: set layout engine without triggering layout update (?)

[jokasimr]

Fixes #499

This does seem to fix

%matplotlib ipympl
import scipp as sc
import plopp as pp
da = sc.data.data_xy()
da.data.values[0, 0] = 1e-23
da.plot(norm='log')
da.plot(norm='log')

I'm not 100% sure why.
My guess is that tight_layout() triggers immediately and is more likely to collide with other updates, but setting the layout engine plays nicer with other concurrent updates.

[nvaytet]

That must have taken a lot of digging! 👍

[jokasimr]

That must have taken a lot of digging! 👍

It did 😅 But I found this issue mentioning a similar problem.

Unfortunately this fix doesn't seem to fix the problem completely... It makes the minimal reproducible example above run as expected. But the Dream tof notebook in essreduce (mentioned in #499) still behave strangely with this fix, some images don't display properly and recreating the images seems to make the notebook hang sometimes.

[nvaytet]

But the Dream tof notebook in essreduce (mentioned in #499) still behave strangely with this fix, some images don't display properly and recreating the images seems to make the notebook hang sometimes.

Is the strange behaviour in Dream notebook also there without the fix from this PR?

[jokasimr]

Is the strange behaviour in Dream notebook also there without the fix from this PR?

No I did not notice the strange behavior before.

Without the fix from this PR the notebook raises

File [~/.local/share/mamba/envs/essreduce/lib/python3.11/site-packages/pyparsing/core.py:307](http://localhost:8888/home/johannes/.local/share/mamba/envs/essreduce/lib/python3.11/site-packages/pyparsing/core.py#line=306), in _trim_arity.<locals>.wrapper(*args)
    305 except IndexError as ie:
    306     # wrap IndexErrors inside a _ParseActionIndexError
--> 307     raise _ParseActionIndexError(
    308         "IndexError raised in parse action", ie
    309     ).with_traceback(None)

_ParseActionIndexError: ('IndexError raised in parse action', IndexError('pop from empty list'))

which is likely the same issue as in the MRE above.

That error goes away with the fix in this PR, but instead there is this strange behavior.

[nvaytet]

Interestingly the issue you mention has had a fix in 3.8.0.
I am wondering what happens if we try to install 3.7? How far back in mpl versions did you go?

[jokasimr]

Here's an requirements.txt file that generates a working environment.
It can handle both the MRE above, and the dream tof notebook in essreduce without errors or other problems.

ipympl
plopp
tof
jupyter
essreduce
ipykernel==6.29.5

If the pin on ipykernel is removed, we get the errors above.

[nvaytet]

If the pin on ipykernel is removed, we get the errors above.

Nice find 👍 If you look at the ipykernel release notes, there is indeed quite a few items that deal with threading.
Did you happen to try with the most recent version of ipykernel to see if anything had been fixed there?

Finally, do we still need to use set_layout_engine or does it no longer matter?

[jokasimr]

Did you happen to try with the most recent version of ipykernel to see if anything had been fixed there?

I've tried without the pin, and that fetches the most recent release, and there it does not work.

Finally, do we still need to use set_layout_engine or does it no longer matter?

Strictly speaking, no. But I think it might be good anyway because, as we saw above, it might mitigate the impact of similar issues should they pop up again in the future. However, maybe that is not worth the risk that it causes a change of behavior. Your call!