consider moving some extensions to separate libraries

[isaacsas]

Issues like https://github.com/SciML/Catalyst.jl/actions/runs/10549534673/job/29224675728?pr=961 are due to some of the extension libraries we depend on not updating to newer (breaking) releases of packages. In this case I think Homotopy continuation, see JuliaHomotopyContinuation/HomotopyContinuation.jl#581, still being on Arblib .8 instead of 1.X is going to block us from updating DynamicPolynomials, but ultimately Symbolics too (which now also requires DynamicPolynmials 6). Note that this isn't an issue with Arblib just recently making a breaking release, v1.0 came out 10 months ago.

It seems like we might want to move such extensions to be separate libraries (i.e. CatalystHomotopyContinuation or such), which would at least allow Catalyst to get updated for everyone that doesn't need to load HomotopyContinuation.

[PBrdng]

Hi, the problem here is that using Arblib 1.0 or newer causes some of the crucial tests in HomotopyContinuation to fail. I'm on it, but I don't know how long it will take to fix this. Sorry!!

[isaacsas]

No worries, and thanks for looking into it!

[ChrisRackauckas]

We can probably relax the DynamicPolynomials. The sad thing is then you'll have a Pkg dependency with DynamicPolynomials v5

[isaacsas]

This may all be indicative that we should split off a Catalyst core at some point.

[isaacsas]

I think I'm going to go ahead with this change in the next few weeks as part of Catalyst 15 unless anyone objects. All the tests that are currently broken seem to be extension-related, and we've had enough cases of extensions holding back dependency updates (and other issues), that I think it makes sense to split them off from core Catalyst. The idea is we'd then have CatalystBifurcationKit, CatalystStructuralIdentifiability, CatalystHomotopyContinuation, etc, which users would explicitly import to get the current extension functionality.

[isaacsas]

The only question is how to handle extensions in the docs with such a change. Perhaps we should just setup the extension-related documentation with the extension libraries, and then just link to it in the Catalyst docs. This would allow us to avoid having Catalyst docs also depend on the extensions (otherwise we will simply move the problem from Catalyst to Catalyst's docs).

[TorkelE]

I'm not keen on doing this right now. Maybe later when I can look at it properly. Last few days have been quite hectic, so haven't been able to look at the tests, but will try to help as soon as possible.

[isaacsas]

What is the benefit to keeping extensions though? As far as I can tell there is none. They aren't really easier on a user, i.e. saying

using Catalyst, BifurcationKit

is basically the same as saying

using Catalyst, CatalystBifurcationKit

and it seems like it would be a big benefit to us in being able to decouple updates to Catalyst from updates to the extension libraries.

[isaacsas]

In fact, we can have CatalystBifurcationKit reexport Catalyst, so a user would only need to say

using CatalystBifuractionKit

[isaacsas]

Also, keep in mind we can setup downstream tests, which we should probably be doing anyways for certain other packages, to check with each PR if the extension library breaks. So we'll still see immediately if updates to core Catalyst break something in an extension ilbrary (but won't be held back from merging those updates to Catalyst and making Catalyst releases).

[TorkelE]

It seems potentially a lot more overhead in that we have to manage several additional packages. And we'd want to have those as downstream tests anyway, so I'm not sure we'd actually gain anything?

I'm not saying that I'm categorically against it. However, I'd actually want to go through what the implications would be when I think of it properly. Maybe we should also discuss through what current and future features of Catalyst we'd want in base/extensions/other packages. Especially as we are reaching a point where things are getting quite settled (baring more changes in MTK).

If we want v15 asap, maybe just mark broken tests as broken, that should be the fastest thing (and also correct, if things are broken).

Edit: saw your comment about downstream tests, you mean like having a separate test set and letting it fail?

[isaacsas]

Making a release with all the extensions broken seems like a bad idea when they are coupled into Catalyst like this. (Hence why decoupling them would be nice, then they could remain on V14 until someone has the time to fix them.)

[isaacsas]

And yes, I mean that we can test each extension library as a downstream test, like MTK does for Catalyst, as part of an additional CI script. When it fails we'd know a PR broke an extension and it needs to be fixed, but that wouldn't prevent us from making Catalyst releases.

[TorkelE]

Moving them out still would not change whether they are broken or not? Short term the whether the functionality does/does not work won't really change. Long term an argument can made, however, all problems (and none until now have caused any major delays) have been related to MTK v9 and follow-up updates. Hopefully, that should calm down (although admittedly whether that is the case is hard to tell).

Either way, I am not directly convinced that separate packages are advantageous, and if we do change it I would actually like to think it through and not rush it.