Found while scoping the ecosystem-adoption work. Small, but it is a real inconsistency in main's Project.toml.
The problem
main declares nine [weakdeps] but only six [extensions]. Three weakdeps have no corresponding extension:
TuringDynamicPPLFlexiChains
And they have zero usage anywhere in src/ (grepped main: no hits for Turing, DynamicPPL or FlexiChains).
The six real extensions are the AD/numerics ones: ChainRulesCore, Enzyme, ForwardDiff, Integrals, Mooncake (["ChainRulesCore", "Mooncake"]), ReverseDiff.
A weakdep with no extension does nothing — it is not loaded, triggers nothing, and just adds noise to the manifest and to [compat] maintenance. These look like leftovers from the composer/Turing work that lives on integration/composed-stack (which does have turing_models.jl), not on main.
Two options
- Remove them from
[weakdeps] (and their [compat] entries) until something on main actually needs them.
- Leave them and land the extension that uses them — see below.
Preferred: option 2, and soon
These three are exactly the weakdeps the planned Turing / as_turing extension (#830) needs. The plan is for main to depend on ComposedDistributions and adopt its uncertain-first inference stack (params_table with the prior column, flatten/unflatten/flat_dimension, ComposedLogDensity/as_logdensity/logdensity, plus the FlexiChains readback: chain_to_params / param_draws / strip_prefix). CD then adds a CD-owned Turing extension driving a Turing model from that spec.
So these three weakdeps are not wrong so much as premature — the extension that justifies them has not landed yet. Worth an explicit decision either way rather than leaving them dangling, since a declared-but-unused weakdep is easy to mistake for a working integration.
Related
This was opened by a bot. Please ping @seabbs for any questions.
Found while scoping the ecosystem-adoption work. Small, but it is a real inconsistency in
main'sProject.toml.The problem
maindeclares nine[weakdeps]but only six[extensions]. Three weakdeps have no corresponding extension:TuringDynamicPPLFlexiChainsAnd they have zero usage anywhere in
src/(greppedmain: no hits forTuring,DynamicPPLorFlexiChains).The six real extensions are the AD/numerics ones:
ChainRulesCore,Enzyme,ForwardDiff,Integrals,Mooncake(["ChainRulesCore", "Mooncake"]),ReverseDiff.A weakdep with no extension does nothing — it is not loaded, triggers nothing, and just adds noise to the manifest and to
[compat]maintenance. These look like leftovers from the composer/Turing work that lives onintegration/composed-stack(which does haveturing_models.jl), not onmain.Two options
[weakdeps](and their[compat]entries) until something onmainactually needs them.Preferred: option 2, and soon
These three are exactly the weakdeps the planned Turing /
as_turingextension (#830) needs. The plan is formainto depend onComposedDistributionsand adopt its uncertain-first inference stack (params_tablewith the prior column,flatten/unflatten/flat_dimension,ComposedLogDensity/as_logdensity/logdensity, plus the FlexiChains readback:chain_to_params/param_draws/strip_prefix). CD then adds a CD-owned Turing extension driving a Turing model from that spec.So these three weakdeps are not wrong so much as premature — the extension that justifies them has not landed yet. Worth an explicit decision either way rather than leaving them dangling, since a declared-but-unused weakdep is easy to mistake for a working integration.
Related
as_turingadaptor — the extension that would use all three)to_constrained/flat_dimensionhoming)This was opened by a bot. Please ping @seabbs for any questions.