Document optional Maxima integration backend

[Amin-El-Sayed]

This adds a short documentation note for external integration methods, with SymbolicIntegrationMaxima.jl as an example optional backend.

The change intentionally keeps the built-in/default behavior unchanged:

• RischMethod and RuleBasedMethod are still described as the built-in methods.
• SymbolicIntegrationMaxima.jl is documented as an external package that provides MaximaMethod.
• The note mentions that the backend requires a local Maxima installation and is not loaded by SymbolicIntegration.jl itself.

[ChrisRackauckas]

That looks really cool! Thanks for sharing. Would you be interested to migrate it to JuliaSymbolics? I am just a little scared of single contributor repos from folks that don't have any other Github history: those tend to get work up front and then just sit without updates after the initial creation. If you would like help with the long term maintenance, we'd be happy to help if moved in here. There probably isn't too much but language bindings are one thing that can be nasty for long term.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.98%. Comparing base (85a221a) to head (8647f0d).
⚠️ Report is 53 commits behind head on main.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #118       +/-   ##
===========================================
+ Coverage   13.91%   50.98%   +37.07%     
===========================================
  Files          22       23        +1     
  Lines        4291     4309       +18     
===========================================
+ Hits          597     2197     +1600     
+ Misses       3694     2112     -1582     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Bumblebee00]

cool thank you @Amin-El-Sayed ! you could copy the file test/rundifficulttests.jl in your repo and sligtly modify it to benchmark the Maxima method against the rule based and risch methods. should be a minimal change but give us a lot of insights

[Amin-El-Sayed]

That looks really cool! Thanks for sharing. Would you be interested to migrate it to JuliaSymbolics? I am just a little scared of single contributor repos from folks that don't have any other Github history: those tend to get work up front and then just sit without updates after the initial creation. If you would like help with the long term maintenance, we'd be happy to help if moved in here. There probably isn't too much but language bindings are one thing that can be nasty for long term.

Thanks, that sounds great. I would definitely be interested in moving it under JuliaSymbolics.
I am quite new to the JuliaSymbolics community and I really wanted to have another fallback option for integration in my new Julia workspace (I also have two other projects of which one might fall under Symbolic.jl in the future).
My goal is for this to become a maintained optional backend in the Symbolics/SymbolicIntegration ecosystem rather than a one-person side package. I am happy to keep helping maintain it, but having it under JuliaSymbolics would be much better for long-term trust, visibility, and maintenance.

What transfer process would you prefer? If you want, I can transfer the existing SymbolicIntegrationMaxima.jl repository to JuliaSymbolics and then update links/docs/registry metadata as needed.

[ChrisRackauckas]

Making it a part of the lib folder in SymbolicIntegration, like how OrdinaryDiffEq.jl does its sublibraries, is the way to keep it alive the most, because then anyone who works on this repo is forced to look at it from time to time. That's what I'd recommend above anything else, but migrating the repo is a second option.

[Amin-El-Sayed]

That sounds like the best path to me. I am happy to move it into SymbolicIntegration.jl as a lib subpackage.

Before I prepare the PR, could you confirm the intended layout? I would assume:

lib/SymbolicIntegrationMaxima/
Project.toml
src/SymbolicIntegrationMaxima.jl
test/runtests.jl
test/rundifficulttests.jl

with the existing package name and UUID kept unchanged.

If that is the right structure, I can prepare the migration PR and adapt the difficult-test comparison there so it reuses SymbolicIntegration.jl's existing test corpus instead of duplicating benchmark data in the external repo.

[ChrisRackauckas]

Just one runtests.jl. https://github.com/SciML/OrdinaryDiffEq.jl/tree/master/lib/DelayDiffEq is an example