SciML / SciML/CatalystNetworkAnalysis.jl

Downgrade CI: SBMLImporter 4 needs Catalyst 16, but old-era compat floors (Catalyst 14.4.1 etc.) are pinned — cascade, needs a minimum-version decision

Open
#73 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Julia
Stars
6
Forks
2
Avg merge
5h 48m
Merged PRs (30d)
6

Description

Summary

The Downgrade (Core) job fails at the Pkg re-resolve (before tests run) with Unsatisfiable requirements detected for package SBMLImporter. This is not fixable by a single compat floor bump — it is a structural mismatch between the test dependency SBMLImporter (pinned to major 4, which is Catalyst-16-only) and the package's still-declared Catalyst-14-era lower compat options. Resolving it requires a real dependency decision (drop the old-era support), so filing for triage rather than silently force-bumping.

Latest failing run: https://github.com/SciML/CatalystNetworkAnalysis.jl/actions/runs/27305595781 (job Downgrade (Core) / Downgrade Tests - Core).

The surface error (and a stale-registry caveat)

The CI log shows:

ERROR: Unsatisfiable requirements detected for package SBMLImporter [210efffb]:
 ├─restricted to versions 4 by project, leaving only versions: 4.0.0-4.1.0
 └─restricted by compatibility requirements with Catalyst to versions: [0.1.0-0.2.0, 2.0.0-2.8.1] — no versions left
    └─Catalyst ... restricted to versions 14.4.1 by an explicit requirement

The Catalyst [0.1.0-0.2.0, 2.0.0-2.8.1] figure in that log is from a stale registry snapshot on the runner. Against the live General registry, SBMLImporter's Catalyst compat is the opposite:

SBMLImporter requires Catalyst
2.x 14
3.x 15
4.x 16

So the true constraint is: SBMLImporter 4 (the pinned test floor) requires Catalyst 16, but the downgrade pins Catalyst to its lowest declared option 14.4.1 → empty intersection.

Verified locally (Julia 1.10 LTS, live registry):

# Catalyst 14.4.1 + SBMLImporter 4.0.0  -> Unsatisfiable
#   "SBMLImporter restricted to 4.0.0 by explicit requirement;
#    Catalyst restricted by SBMLImporter to 16.0.0-16.2.0 — no versions left"
# Catalyst 16.0.0 + SBMLImporter 4.0.0  -> resolves (Catalyst 16.0.0, SBMLImporter 4.0.0)

Why a single floor bump does not fix it (cascade)

Project.toml declares many disjoint "old, new" compat ranges — the old (Catalyst-14-era) option plus a newer (Catalyst-16 / Oscar-1.7-era) option added in 32df9a3 "Upgrade to Catalyst 16 / Oscar 1.7 stack":

Catalyst                 = "14.4.1, 16"
SymbolicUtils            = "3.7.2, 4"
ModelingToolkit          = "9.46.1, 11"
Oscar                    = "1.1.1, 1.7"
Hecke                    = "0.34, 0.39"
Nemo                     = "0.47, 0.54, 0.56"
Polyhedra                = "0.7.8, 0.8"
ReactionNetworkImporters = "0.15.1, 1.3"
CDDLib                   = "0.9.4, 0.10"

The downgrade pins each to its lowest option. Because SBMLImporter 4 forces Catalyst 16, the entire old-era floor set is dead, and bumping only Catalyst exposes a chain of further old-era floor conflicts (all verified locally against the live registry at the 1.10 LTS floor):

  1. Catalyst 14.4.1 vs SBMLImporter 4 (needs Catalyst 16) — the reported failure.
  2. SymbolicUtils 3.7.2 vs Catalyst 16.0.0 (needs SymbolicUtils ≥ 4.9.1).
  3. Nemo 0.47.0 vs Hecke 0.34.0 (Hecke 0.34.x needs Nemo 0.47.1-0.47).
  4. Hecke 0.39.0 vs Nemo 0.54.0 (the Oscar/Hecke/Nemo trio is version-locked; the floor pair does not co-resolve).

No single bump resolves this; the old-era lower options are collectively incompatible with the SBMLImporter-4 test requirement.

Recommended fix (a real dep decision — hence this issue)

The latest-versions CI already resolves and the Core tests pass on the new-era stack (green job https://github.com/SciML/CatalystNetworkAnalysis.jl/actions/runs/27305595949 installed: Catalyst 16.2.0, Oscar 1.7.3, Nemo 0.54.2, Hecke 0.39.15, SymbolicUtils 4.35.0). The old-era lower options are leftovers and are not co-installable with the pinned SBMLImporter 4.

If CatalystNetworkAnalysis no longer needs to support the Catalyst-14 era (which seems to be the case given SBMLImporter is pinned to 4), the clean fix is to drop the dead old-era lower options and pin the disjoint compats to a coherent Catalyst-16-stack minimum, e.g.:

Catalyst                 = "16"
SymbolicUtils            = "4"          # (Catalyst 16 needs ≥ 4.9.1)
ModelingToolkit          = "11"
Oscar                    = "1.7"
Hecke                    = "0.39"
Nemo                     = "0.54, 0.56"
Polyhedra                = "0.8"
ReactionNetworkImporters = "1.3"
CDDLib                   = "0.10"

The exact minimal floor for the Oscar/Hecke/Nemo trio must be co-selected (they are lockstep-versioned; the green build used Hecke 0.39.15 / Nemo 0.54.2). This is a deliberate "minimum supported version" decision, which is why I'm filing it for maintainer sign-off rather than mechanically force-bumping every floor.

Alternatively, if Catalyst-14-era support is intended to be retained, the SBMLImporter test-dep floor would need to be widened down (e.g. SBMLImporter = "2, 4") so a Catalyst-14-compatible SBMLImporter exists at the floor — but that likely loses SBMLImporter 4 features and is also a real decision.

(Note: the latest-versions QA (julia 1) and Documentation jobs are also red on main, but for unrelated reasons — not this downgrade resolution wall.)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the compatibility entries in Project.toml and reproduce the resolver failure in the Downgrade (Core) CI job using the live registry. Review the listed Catalyst, SBMLImporter, SymbolicUtils, Oscar, Hecke, Nemo, and related constraints with maintainers. Done means a deliberate minimum-version choice is recorded and the downgrade job resolves and passes its Core tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
build-system, ci-cd
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.