downgrade-compat CI job fails: ModifiedDistributions missing from manifest

[seabbs-bot]

What's failing

The downgrade-compat / Downgrade Compat job in the Test workflow has been failing on main for at least the last several runs, independent of any in-flight PR:

• https://github.com/EpiAware/DistributionsInference.jl/actions/runs/29681937891/job/88179509844 (main @ 105cd33)
• https://github.com/EpiAware/DistributionsInference.jl/actions/runs/29680621727 (main @ 80cd1e0)
• https://github.com/EpiAware/DistributionsInference.jl/actions/runs/29654794679 (main @ 73c8332)

Error:

`ModifiedDistributions` is a direct dependency, but does not appear in the manifest. If you intend `ModifiedDistributions` to be a direct dependency, run `Pkg.resolve()` to populate the manifest. Otherwise, remove `ModifiedDistributions` with `Pkg.rm("ModifiedDistributions")`. Finally, run `Pkg.instantiate()` again.

The job runs:

Pkg.test(;coverage=true, julia_args=["--check-bounds=yes", "--compiled-modules=yes", "--depwarn=yes"], test_args=["skip_quality"], force_latest_compatible_version=false, allow_reresolve=true)

Likely cause

test/Project.toml declares ModifiedDistributions as a direct [deps]/[compat] entry, pinned via [sources] to a git URL since it is unregistered:

[sources]
ModifiedDistributions = {rev = "main", url = "https://github.com/EpiAware/ModifiedDistributions.jl"}

This mirrors the existing ComposedDistributions pin in the same file (which does not fail the same job), so the [sources]-pinning pattern itself isn't inherently broken — something about the downgrade-compat resolution path (force_latest_compatible_version=false) specifically drops or fails to resolve the ModifiedDistributions git-sourced entry into the downgraded manifest. Worth comparing against how ComposedDistributions.jl and ModifiedDistributions.jl's own test/docs envs handle the equivalent pin in their downgrade-compat jobs, since they may have already hit and fixed this.

Why this is filed separately

Found while reconciling PR #39 (org docs-funnel sweep) against PR #21 — confirmed this failure predates and is unrelated to both docs PRs by checking that main's own recent Test workflow runs fail identically with no docs changes involved.

This was opened by a bot. Please ping @seabbs for any questions.

[seabbs-bot]

Root cause found (reproduced locally, Julia 1.12.6)

This is not a problem with the [compat] bound on the two [sources]-pinned
packages themselves. I tried removing ComposedDistributions = "0.1" /
ModifiedDistributions = "0.1" from test/Project.toml (matching
ModifiedDistributions.jl's own test env, which carries no compat entry for its
[sources]-pinned deps) and re-ran the full pipeline -- identical failure.

The actual chain, reproduced by running the real julia-downgrade-compat
action (Resolver.jl, mode deps) followed by the real Pkg.test(...) call
julia-runtest uses:

1. downgrade.yml's floor-resolve only touches the root Project.toml
   (merged with test/Project.toml compat for bound purposes); it
   deliberately skips resolving [sources]-pinned packages into the
   manifest at all (both ComposedDistributions and ModifiedDistributions
   are absent from the manifest after this step -- not just one of them).

2. When julia-runtest's Pkg.test(...) later tries to add them back in
   (allow_reresolve=true), it hits a real, unsatisfiable version
   conflict, not a resolver quirk. Running Pkg.resolve() directly against
   test/Project.toml (rather than through Pkg.test's internal path, which
   swallows the real diagnostic into the generic "does not appear in the
   manifest" message) surfaces it clearly:

   ERROR: Unsatisfiable requirements detected for package ConvolvedDistributions [f5b942c9]:
    ├─restricted to versions 0.2 by ModifiedDistributions [664e6f8c] (fixed to 0.1.0, git main)
    ├─restricted to versions 0.2 by ComposedDistributions [2f642b71] (fixed to 0.1.0, git main)
    └─restricted by compatibility requirements with OptimizationOptimJL [36348300] to versions:
      uninstalled -- restricted to 0.3.2 by an explicit requirement (the downgrade-floor's
      pin from DI's own Turing/Optimization graph)
   

   ComposedDistributions/ModifiedDistributions's git main both now
   require ConvolvedDistributions >= 0.2 (Sam merged Convolved#73,
   main -> 1.0.0, today). ConvolvedDistributions itself requires
   OptimizationOptimJL >= 0.4.3 (weak, via its Optimization extension), but
   the downgrade-compat floor-resolve already pinned OptimizationOptimJL at
   its own floor (0.3.2) for DI's unrelated Turing/Optimization deps. The
   merged floor-resolve promotes weakdeps into hard constraints for the joint
   floor test, so this is a genuine conflict, not just a message-quality bug.

This is entangled with the live Convolved 1.0 migration, not a DI-only fix

This is the same "Convolved-1.0 compat wave" flagged separately for CD/LD
(ComposedDistributions#247 widens ConvolvedDistributions = "0.2" ->
"0.2, 1"). Important extra finding: that widening alone is not
sufficient for a clean fix, because ComposedDistributions' own source
(src/composers/convolved_interop.jl, in a @doc @example block executed
by Documenter) still calls ConvolvedDistributions.discretise_pmf, which
Convolved 1.0.0 removed per its own NEWS.md. ModifiedDistributions' extension
(ext/ModifiedDistributionsConvolvedDistributionsExt.jl) does the same. So
raising the compat bound without migrating those call sites will trade this
"missing from manifest" failure for a runtime/Documenter failure once
resolution actually picks 1.0.0.

Recommendation: this issue is blocked on the Convolved 1.0 migration
completing on the ComposedDistributions/ModifiedDistributions side (compat
widening and the discretise_pmf/DelayPMF call-site migration -- tracked
elsewhere per Sam, e.g. the "DelayPMF retirement" work), not something to fix
independently in DI's test/Project.toml. Once that lands, re-run DI#12/#13
and this downgrade-compat job should resolve cleanly without any DI-side
change. Leaving this issue open, retitled scope note added, not closing.

This was opened by a bot. Please ping @seabbs for any questions.

[seabbs-bot]

Cross-repo evidence from ModifiedDistributions.jl#92 (the DIT-0.11 dependency-bump PR, dependabot-authored): the same downgrade-compat / Downgrade Compat job fails with the identical error class, just naming a different unregistered, [sources]-git-pinned direct dependency:

`ComposedDistributions` is a direct dependency, but does not appear in the manifest. If you intend `ComposedDistributions` to be a direct dependency, run `Pkg.resolve()` to populate the manifest. Otherwise, remove `ComposedDistributions` with `Pkg.rm("ComposedDistributions")`. Finally, run `Pkg.instantiate()` again.

• Post-fix run (my ConvolvedDistributions pin-back, commit 485255e): https://github.com/EpiAware/ModifiedDistributions.jl/actions/runs/29778520320/job/88473746986
• Pre-fix run (ad9f946, before my commit existed): https://github.com/EpiAware/ModifiedDistributions.jl/actions/runs/29763421551/job/88423478681

Same failure, identical wording, fires on both — confirms it's unrelated to the specific Project.toml edit in that PR and predates it, matching your note here that ComposedDistributions's pin in the same file "does not fail the same job" under other circumstances, so this looks actor/mode-dependent rather than pin-shape-dependent.

Two things that narrow it further:

1. Actor-dependent: MD's downgrade-compat job runs with force_latest_compatible_version set to true here (this PR is dependabot-authored, and the job's own log prints "This is a Dependabot/CompatHelper job, so force_latest_compatible_version has been set to true"), vs your false on DI's main-branch runs. Both modes hit the same manifest-desync symptom, so the common factor is allow_reresolve=true plus a [sources]-git-pinned direct dependency under mode: deps compat-flooring, not the force-latest value itself.
2. Non-reproducing locally: I tried to reproduce on Julia 1.12.6 (fresh resolve, root Project.toml compat manually floored to match what julia-downgrade-compat's mode: deps does, force_latest_compatible_version=true, allow_reresolve=true) and got a clean pass (2147/2147) both with and without the floor — so whatever triggers the manifest desync needs the actual CI runner state (exact Julia patch version, or something julia-downgrade-compat@v2/julia-runtest@v1 do beyond a plain Pkg.test call) that I couldn't replicate directly.

Separately, while diagnosing MD#92's other red leg (test (pre, *), which is non-blocking/continue-on-error so not the same bug): Julia 1.13.0-rc1 (what "pre" currently resolves to) appears to merge a git-pinned dependency's own workspace-member [sources] (e.g. LoweredDistributions' test/Project.toml still git-pinning ConvolvedDistributions to rev="main") into the consuming project's resolve, where stable Julia 1.12 correctly ignores it (matching this org's own documented [sources]-scoping convention). I couldn't install 1.13.0-rc1 locally to confirm the exact mechanism, but the CI log's git-clone sequence is unambiguous. Flagging here since every repo in the org git-pins its unregistered siblings the same way — if that nested-merge behaviour ships in 1.13 proper, the interim pin-backs (like this one) matter more than they do today, since a sibling's own stale pin can leak through even after a consumer's own environments are clean.

This was opened by a bot. Please ping @seabbs for any questions.