Why
Without a predictable arithmetic contract from linopy, linopy_yaml cannot guarantee consistent behavior. A YAML expression like sum(p * cost, over=generator) compiles differently depending on operand order, coordinate alignment, and NaN handling:
We park stability on the upstream v1 convention refactor rather than working around these in our parser/builder.
Upstream tracking
Action for linopy_yaml once v1 is released
- Opt into v1 globally:
linopy.options["arithmetic_convention"] = "v1" in from_yaml() (or at module import).
- Un-xfail the dispatch tests and verify they pass.
- Document in
SPEC.md that linopy_yaml requires the v1 convention.
- Drop any workarounds that exist to paper over legacy-convention quirks.
Sub-issues that directly affect linopy_yaml today
Close when
linopy ships the v1 convention as a released version, linopy_yaml has migrated, and the dispatch xfail markers are removed.
Why
Without a predictable arithmetic contract from linopy,
linopy_yamlcannot guarantee consistent behavior. A YAML expression likesum(p * cost, over=generator)compiles differently depending on operand order, coordinate alignment, and NaN handling:We park stability on the upstream v1 convention refactor rather than working around these in our parser/builder.
Upstream tracking
linopy.options["arithmetic_convention"] = "v1"with strict coordinate matching, explicit NaN handling, and formal algebraic law tests.Action for
linopy_yamlonce v1 is releasedlinopy.options["arithmetic_convention"] = "v1"infrom_yaml()(or at module import).SPEC.mdthatlinopy_yamlrequires the v1 convention.Sub-issues that directly affect
linopy_yamltodayp * costpatterns)sum(...)helpers)Close when
linopy ships the v1 convention as a released version,
linopy_yamlhas migrated, and the dispatchxfailmarkers are removed.