Adopt linopy's solver design: no forced solver, declared capabilities, lazy availability

[FBumann]

Thread A of #105, researched. Read against linopy 0.9.x as installed.

linopy already forces no solver

Its hard dependencies contain no solver at all:

numpy, scipy, bottleneck, toolz, numexpr, xarray>=2024.2.0,
dask>=0.18.0, polars>=1.31.1, tqdm, deprecation, packaging

Solvers live behind one extra:

[solvers] = gurobipy, highspy, cplex (non-Darwin), mosek, mindoptpy,
            coptpy, xpress (non-Darwin), pyscipopt (non-Darwin), knitro

with platform markers doing the work where a wheel does not exist everywhere. Since our compat lane is a pure consumer of linopy's public API, matching this is coherent rather than merely imitative — and it settles the question in #105: highspy moves out of dependencies.

What is worth adopting

1. Two implementation paths behind one ABC. Solver declares _run_file (LP/MPS) and _build_direct / _run_direct (in-process API), with accepted_io_apis: ClassVar[frozenset[str]] saying which a given solver supports. That maps exactly onto our two sinks — lp_file and solver_direct — and is the seam we need, because solver_direct is currently highspy-specific (addCols / addRows / changeColsIntegrality are highspy APIs).

2. io_api as an axis orthogonal to solver choice.

FILE_IO_APIS = ["lp", "lp-polars", "mps"]
IO_APIS = FILE_IO_APIS + ["direct"]

We already have this distinction and have never named it. Naming it makes "which solvers can this model reach, and how" answerable.

3. Availability probing with no import side effects. Three separate mechanisms, all worth copying:

• _has_module uses importlib.util.find_spec — never executes the package's __init__.
• _LazyModule is a proxy importing on first attribute access, so gurobipy.Env can be referenced at module level while deferring the import "and its license-server side effects, for mindoptpy/coptpy".
• _AvailableSolvers is a lazy Sequence[str] behind functools.cached_property, with an explicit refresh().

The license-server point is the non-obvious one: for commercial solvers, importing is not free.

4. Licensing is a separate, opt-in probe. Membership in available_solvers means importable, explicitly not licensed; check_solver_licenses() is the eager check. Conflating the two would make availability slow and network-dependent.

5. SolverFeature — Track 4, already built upstream. A 15-member enum declared per solver class as ClassVar[frozenset[SolverFeature]], queried via cls.supports(feature):

INTEGER_VARIABLES, QUADRATIC_OBJECTIVE, DIRECT_API, LP_FILE_NAMES,
READ_MODEL_FROM_FILE, SOLUTION_FILE_NOT_NEEDED, GPU_ACCELERATION, GPU_ONLY,
IIS_COMPUTATION, SOS_CONSTRAINTS, INDICATOR_CONSTRAINTS,
SEMI_CONTINUOUS_VARIABLES, SOLVER_ATTRIBUTE_ACCESS, MIP_DUAL_BOUND_REPORT

That list covers precisely what ARCHITECTURE names as the sink upgrade path (sos_sets, genconstr, a semi-continuous threshold on cols) plus what ROADMAP Track 2b wants (IIS_COMPUTATION).

The one place adoption is not 1:1 — and it matters

linopy attaches capability to the solver. ARCHITECTURE.md attaches it to the sink, and is explicit that "capability is not the ceiling":

lp_file carries [SOS] as a text section and Gurobi natively

Both models are right about different things. An LP file can serialise SOS whether or not the solver eventually reading it understands it; a direct API can accept SOS whether or not any file format was involved. So capability is really a property of the (sink, solver) pair, not of either alone.

Deciding this is the substantive design question here, and it should be settled before any code:

• declare features on sinks only, and treat the solver as one more sink?
• declare on both and intersect?
• keep linopy's solver-only model and accept that check(model, sink=...) answers a narrower question than it appears to?

What we should not adopt

• Stateful Solver objects. linopy's carries status, solution, solver_model, snapshot, _rebuilds, _in_place_updates, plus track_updates persistent-update machinery. Our api.py is deliberately three verbs and the executor owns lifetime; importing that state model would fight it. Warm starts are a separate conversation.
• One 4,520-line module holding 13 solver classes.
• Default-by-probe-order. _SOLVER_PROBE_ORDER makes the first installed solver the default in Model.solve. That means the same YAML solves with a different solver on a different machine — the opposite of "the file is the source of truth". We should require an explicit solver=, or at minimum make the implicit choice loud.

Incidental finding, relevant to #105

linopy hard-depends on polars>=1.31.1 and ships an lp-polars io_api — it writes LP files through polars. So the compat extra already pulls polars in transitively, and "polars is exotic in this ecosystem" is not a defensible argument against it.

Work this implies

1. Move highspy to [highs]; add a [solvers] bundle; nothing installed by default.
2. solve() with no solver installed raises naming the extras, as to_dataarray already does for xarray.
3. Implement .mps — with no solver by default, the file sinks become the universal interface (see Nothing should be forced: make the solver, the dataframe library, and Arrow all optional #105).
4. Split solver_direct behind a small ABC before a second direct solver exists, not after.
5. Decide the sink-vs-solver capability axis above; that is ROADMAP Track 4.

[FBumann]

Correction: their LP file is transport, ours is a product

The io_api recommendation above is too glib — the two projects use a file for different purposes, and copying the vocabulary would import the wrong model.

linopy: the file is an intermediate. Solver._build calls model.get_problem_file(io_api=...) (a temp path by default), model.to_file(...) writes it, _run_file invokes the solver on it, and a solution_fn is read back. Evidence that this round-trip is lossy and costly:

• _parse_int_label, _names_to_labels, _solution_from_names exist to map solver-reported names back to integer labels — with three fallback strategies including two regexes. The docstring is explicit: "Used by paths where the solver may iterate in arbitrary order or drop unused entities (file-based LP solvers, the from_file paths of Highs/Gurobi)."
• LP_FILE_NAMES is a declared SolverFeature — i.e. "does this solver preserve my names well enough to find my values again".
• read_sense_from_problem_file and read_io_api_from_problem_file re-parse the file to recover context that was lost writing it.

Ours: write_lp is a terminal sink. The user keeps the file; it exists for portability, debugging and the differential oracle. solver_direct never touches a file, and there is no read-back path at all.

So io_api in linopy is transport negotiation; the equivalent list in ours is a product menu. accepted_io_apis per solver would conflate "can this sink emit it" with "can this solver ingest it" — which is the same sink-vs-solver axis confusion flagged above, in a second guise.

The fork this forces

Do we ever want file-based solver invocation? It is the only way to reach solvers with no Python API (cbc, glpk binaries), so "no solver is forced" makes it more attractive, not less.

If no — every supported solver must have a Python API, solver_direct is the only solve path, and accepted_io_apis collapses to nothing. The ABC reduces to _build_direct / _run_direct, and none of linopy's name-parsing layer is needed. Much simpler, and it keeps lp_file purely a product.

If yes — LP/MPS serve two masters, and the column-naming question stops being cosmetic:

	wants
debugging / portability	real names — p[wind,3], so a solver error or IIS points back at a YAML declaration
solver transport	stable integer identity — cheap, unambiguous round-trip

Our current printf('x%d', col) is ideal for transport: because col is the dense label, reading a solution back is a pure integer parse with no fallback chain — the exact cost linopy pays for having richer names. It is correspondingly bad for debugging, which is what a terminal artifact is mostly for.

If the file becomes transport, the resolution is probably real names in the file plus a sidecar label table, or a naming mode per call — but that is a decision to take deliberately, and it is currently made by accident.

Recommend deciding this fork before any of the ABC work, since it determines whether the ABC has one path or two.

[FBumann]

Correction to "what we should not adopt": ruling out stateful solver objects was wrong. DuckdbExecutor is already a long-lived context manager that ly.build() hands back, and iterative workflows genuinely need the native solver model held between solves. What should not be adopted is narrower — the ModelSnapshot / RebuildReason diff machinery, which exists to infer what changed in a user-mutable model. Ours is declared, so we can classify a program as warm-startable statically from its predicates. Split out to #108, which also constrains the ABC here.