Tracking removal from Turing-verse

[gdalle]

Sofar the rationale is still unclear, but Turing seems to be moving away from DI. Listing the relevant issues, PRs and commits here for future reference:

Moving to native interfaces

• Use native gradient API for ForwardDiff, Enzyme, Mooncake TuringLang/DynamicPPL.jl#1354
• Use native gradient API for ForwardDiff, Enzyme, Mooncake TuringLang/Bijectors.jl#458
• Add evaluator interface with AD backend extensions TuringLang/AbstractPPL.jl#155
• Enzyme type piracy  TuringLang/AdvancedVI.jl#247, TuringLang/AdvancedVI.jl@7972f1a and Native autograd interface TuringLang/AdvancedVI.jl#249
• Use native gradient API TuringLang/JuliaBUGS.jl#449
• Use structural AbstractPPL AD prep for LogDensityFunction TuringLang/DynamicPPL.jl#1365

Implementing higher-level API in Mooncake

• Add value_and_jacobian chalk-lab/Mooncake.jl#1145, Add cached value_and_jacobian!! interface. chalk-lab/Mooncake.jl#1153
• [Part 3/3] Add public HVP and Hessian API; clean up CI and test infrastructure chalk-lab/Mooncake.jl#1091

[yebai]

I previously encouraged the Turing software engineers to move away from LogDensityProblemsAD in favour of DI and ADTypes. Since then, however, DI has become much less actively maintained, and I now consider the centralised AD-wrapper model to be unsustainable. In my view, DI solved the wrong problem. For libraries such as Turing, Flux, and Lux—both of which have already rejected DI—direct integration with autodiff libraries is straightforward and incurs little maintenance cost. Eliminating this layer of indirection would free capacity for more important engineering work and research.

See, #999 (comment)

[gdalle]

Can you point to specific issues in DI that you would need to be solved?

[gdalle]

See also TuringLang/AdvancedVI.jl@7972f1a#commitcomment-182520277