What
CTParser's newest version (0.9.3-beta) still declares:
Every other package in OptimalControl's dependency graph that depends on CTBase has already
widened past this floor (CTSolvers 0.5.6-beta: "0.29-0.30", CTLie 0.2.1-beta: "0.29-0.30",
CTFlows 0.18.0-beta: "0.30"). CTDirect is the other blocker, tracked separately as
CTDirect#629 — but CTParser sits
one level under CTDirect in the graph (CTDirect depends on CTParser, and OptimalControl depends
on it directly too), so fixing CTDirect alone isn't enough: CTParser becomes the next blocker as
soon as CTDirect's is resolved.
Reproduction
Verified directly: took a local CTDirect checkout, patched only its own [compat] to
CTBase = "0.29, 0.30" / CTModels = "0.18, 0.19" (i.e. simulated CTDirect#629's fix), Pkg.developed
it into OptimalControl with CTBase = "0.30" in [compat]. The resolve then fails on CTParser,
not CTDirect:
ERROR: Unsatisfiable requirements detected for package CTParser [32681960]:
CTParser [32681960] log:
├─possible versions are: 0.2.0 - 0.9.3 or uninstalled
├─restricted to versions 0.9 by OptimalControl [5f98b655], leaving only versions: 0.9.0 - 0.9.3
└─restricted by compatibility requirements with CTBase [54762871] to versions: uninstalled — no versions left
└─CTBase [54762871] log:
├─possible versions are: 0.11.2 - 0.30.2 or uninstalled
└─restricted to versions 0.30 by OptimalControl [5f98b655], leaving only versions: 0.30.0 - 0.30.2
Ask
A CTParser release that widens
CTBase = "0.29, 0.30" # or "0.30" if 0.29 support isn't worth keeping in range
No source change expected — pure compat-range widening, same shape as CTSolvers#225 / CTLie#33 /
the fix for CTDirect#629, unless CTParser's own code touches something CTBase 0.30 changed.
Why it matters downstream
Same reason as CTDirect#629: this is one of the two things (alongside CTDirect#629) standing
between OptimalControl and documenting the completed Makie plotting backend — tracked in
control-toolbox/OptimalControl.jl .reports/campaign/upstream.md.
Found while re-checking whether CTDirect#629's fix alone would be sufficient.
🤖 Generated with Claude Code
What
CTParser's newest version (0.9.3-beta) still declares:
Every other package in OptimalControl's dependency graph that depends on CTBase has already
widened past this floor (CTSolvers 0.5.6-beta:
"0.29-0.30", CTLie 0.2.1-beta:"0.29-0.30",CTFlows 0.18.0-beta:
"0.30"). CTDirect is the other blocker, tracked separately asCTDirect#629 — but CTParser sits
one level under CTDirect in the graph (CTDirect depends on CTParser, and OptimalControl depends
on it directly too), so fixing CTDirect alone isn't enough: CTParser becomes the next blocker as
soon as CTDirect's is resolved.
Reproduction
Verified directly: took a local CTDirect checkout, patched only its own
[compat]toCTBase = "0.29, 0.30"/CTModels = "0.18, 0.19"(i.e. simulated CTDirect#629's fix),Pkg.developedit into OptimalControl with
CTBase = "0.30"in[compat]. The resolve then fails on CTParser,not CTDirect:
Ask
A CTParser release that widens
No source change expected — pure compat-range widening, same shape as CTSolvers#225 / CTLie#33 /
the fix for CTDirect#629, unless CTParser's own code touches something CTBase 0.30 changed.
Why it matters downstream
Same reason as CTDirect#629: this is one of the two things (alongside CTDirect#629) standing
between OptimalControl and documenting the completed Makie plotting backend — tracked in
control-toolbox/OptimalControl.jl
.reports/campaign/upstream.md.Found while re-checking whether CTDirect#629's fix alone would be sufficient.
🤖 Generated with Claude Code