Drop Mooncake from DI support?

[yebai]

DI currently places an upper bound on Mooncake, which has caused significant downstream disruption for multiple packages, including SciML and Turing.jl. This constraint propagates through the dependency graph, so it affects environments even when Mooncake is not used directly via DI (e.g. in Turing.jl), leading to unnecessary version conflicts and reduced composability.

One contributing factor is that maintaining compatibility with DI’s test suite—particularly for less universally supported types such as StaticArrays—can impose a nontrivial maintenance burden on AD backends like Mooncake.

If this cost is disproportionate, one viable option would be for DI to drop support for Mooncake entirely. A clean separation would avoid recurring breakages and simplify dependency management, rather than relying on tight version bounds that impact unrelated users.

Alternatively, if support is retained, it may be worth reconsidering the scope of the test suite and clarifying expectations around supported types, so that compatibility requirements are both explicit and realistically maintainable.

[yolhan83]

That would indeed simplify the maintenance in DI and in Mooncake but for sciml of any other orgs depending on DI double the code to support Mooncake outside of DI, and at the end it may lead to someone making a fork of Mooncake just to have a proper backend in DI and that would lead to an even worse situation for everyone. For now the best thing to do is making sure the compat issue gets resolved as fast as possible and the compat limit gets removed I guess.

[gdalle]

Indeed, as explained on Slack removing Mooncake from DI will not be considered. The compat issue is being worked on, but not on Sundays. It will be solved tomorrow.

[ChrisRackauckas]

but not on Sundays

The French mindset is beautiful. Teach me someday.

One contributing factor is that maintaining compatibility with DI’s test suite—particularly for less universally supported types such as StaticArrays—can impose a nontrivial maintenance burden on AD backends like Mooncake.

Users like SciML are still going to ask for that support. The question is whether SciML finds and opens the issues or DI. It's really nice for us that DI has a centralized suite that tests some basic types and ensures they are handled. What SciML users manage to throw in is... even more than what DI tests haha, we definitely have some special snowflake codes out there, but it's good that all of those cases get tested and upstream issues before it ever hits my test suite. So I don't see how this changes anything.

But, issues open on Mooncake are a Mooncake thing which you can say yes/no to independently. StaticArray support in Mooncake is definitely an issue to think about, we hit it and have an issue open for it too SciML/SciMLSensitivity.jl#1425. But it looks like it's fundamental to the system, i.e. it would be hard for Mooncake to support static arrays because all of its internal buffers assume mutation on arrays, not just support it but also assume mutation and use it for the pullbacks. Which 🤷 if that's the case, then that's the reason for DI: we just tell users to not use Mooncake when their code has static arrays and move on.

[yebai]

I would strongly encourage the DI developers to remove support for Mooncake for two reasons.

1. It depends on Mooncake internals and is therefore likely to be unstable given Mooncake’s rapid evolution. This differs from other autograd libraries, such as ForwardDiff, whose internals are largely stable.
2. DI’s approach of centralising autograd wrappers is prone to version conflicts, as already observed. These conflicts can be highly disruptive for downstream libraries such as Turing.jl.

For context, Mooncake is MIT licensed, so there is no obligation to remove support for it. That said, the Mooncake team’s view is that this support should be removed.