Support CairoMakie above 0.13

[pkofod]

I suppose the restriction is just there because these are breaking changes due to sub 1.0 minor changes.

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Add any other context about the problem here.

[pkofod]

Not sure if any tests are supposed to fail here

[jkrumbiegel]

Makie is also restricted here

[jkrumbiegel]

graphmakie is also at 0.6 now with Makie 0.24 compat

[pkofod]

I updated graphmakie and makie, but would it be better to keep 0.5 and 22.2.1 in there in terms of allowing a flexible set of packages if they all work with catalyst?

[TorkelE]

I am not too surprised some errors have snuck in into CI over the last while. Catalyst is based on ModelingToolkit, which had a new breaking change a while ago that we have not had time to update to. In tandem with that there have been updates to MTK-related packages, it probably some change there made assumptions that means these errors happens if you are not using the latest ModelingToolkit.

Hopefully we will be able to make an update soon. A major hindrance is that the next ModelingToolkit breaking release is due very soon, so we are simply waiting for that one and skipping a step. Thanks for the PR though, we will integrate as soon as possible once CI works properly again.

[devmotion]

Catalyst pins MTK to v9, so CI and releases should be unaffected by breaking changes in MTK.

Similar to how I recently backported support for ForwardDiff@1 and [email protected] to MTK@9, I think it would be good to update/backport compat entries (apart from breaking MTK and SciML releases, of course) to the latest Catalyst version as much as possible.

[TorkelE]

So, in theory that should work. But what may have happened is that some other of the many MTK-adjacent packages have made some form of update which implicitly assumed that MTK v10 has happened, but does not explicitly require MTK v10, and hence is pulled in and causes the error. At least that is my guess, as the CI errors I saw don't really relate to Makie, but had something to do with indexing of MTK structures.

[devmotion]

If these errors are not caused by CairoMakie, then the same errors should show up when running tests on master or the latest release of Catalyst.

SciML packages are unfortunately pretty bad with stable non-breaking releases in my experience, but that's something to be sddressed separately (eg by fixing incorrect SciML compat entries in Catalyst or other packages).

I think nobody should expect an immediate update to MTK@10, given the amount of breaking and fundamental changes and that MTK@11 is supposed to be released soonish. But I think it's annoying for many users and downstream packages if Catalyst is blocking updates of unrelated dependencies such as plotting packages.

[TorkelE]

Didn't think of that this might affect more downstream stuff, that is annoying, definitely. I have started CI, if the error is in MTK indexing, maybe we can try capping SymbolicIndexingInterface. That is the package which does most of the heavy lifting here, could be it.

[pkofod]

Didn't think of that this might affect more downstream stuff, that is annoying, definitely. I have started CI, if the error is in MTK indexing, maybe we can try capping SymbolicIndexingInterface. That is the package which does most of the heavy lifting here, could be it.

thanks!

[jkrumbiegel]

Looks like BifurcationKit's compat also has to be updated as it also has a weakdep on Makie. It already has a version updated to Makie 0.24

[devmotion]

I see similar (same?) test failures in #1338 which reruns CI on master. I haven't checked all logs yet but e.g. https://github.com/SciML/Catalyst.jl/actions/runs/19298250248/job/55185564290?pr=1338 is mainly a problem with the existing tests in Catalyst being somewhat flaky and probably an upstream fix in a newer version of some SciML package - IMO the tests should just check SciMLBase.successful_retcode(sol) instead of explicitly comparing the return code with e.g. SciMLBase.ReturnCode.Success or SciMLBase.ReturnCode.Terminated (as documented: https://github.com/SciML/SciMLBase.jl/blob/ff00df899cad8438f018705c5da7eec0960e909e/src/retcodes.jl#L16-L23).

[TorkelE]

I would have to investiagate closer what is happening, but unless you are talking about a specific case I am not sure exactly what you mean? I.e. in the file which causes the error (1, Core), the only retcode-related test is a

@test SciMLBase.successful_retcode(sol)

and I don't think that is related to the failure here.

[devmotion]

No, the problem I was pointing to was in the Hybrid tests and is caused by

Catalyst.jl/test/simulation_and_solving/hybrid_models.jl

Line 109 in 64c117f

@test sol.retcode == ReturnCode.Terminated

. I opened a PR with a fix: #1339 I haven't checked the other errors yet.

[devmotion]

But regardless of the exact nature of the CI failures - if the same errors are present on the master branch and even more importantly the latest release (I assume they are since it seems there are no implementation changes on master apart from an updated compat entry for Optimization: v15.0.8...master), then there is no harm in merging PRs like this compat update, assuming the relevant plotting tests pass and these versions are actually tested. Users could already run into these issues, so the new release would not make anything worse in that regard; on the contrary, however, users that are currently blocked from e.g. updating CairoMakie would be able to benefit from the latest improvements and bug fixes in CairoMakie.