Ask
Migrate rain-interpreter-interface to rain-math-binary 0.1.3 and publish, so the consumers blocked behind it can move.
This issue exists to be a typed blocker ref. Five consumer PRs are stuck and cannot route to ai:blocked-on because flag-blocked-on refuses without a --blocked-by owner/repo#n and there was nothing to name.
Why they are stuck
Consumers set [soldeer] recursive_deps = false and use version-suffixed remappings, so the consuming repo's own remappings.txt must satisfy the hard-coded imports inside its dependencies. Bumping a consumer to rain-math-binary 0.1.3 removes the rain-math-binary-0.1.1/ prefix that dependency source still hard-codes, and compilation fails.
Reproduced locally under the pinned toolchain (nix develop github:rainlanguage/rainix/53e96a7d…#sol-shell -c forge build) on rain.pyth#32, failing on three dependency files, each import {LibCtPop} from "rain-math-binary-0.1.1/src/lib/LibCtPop.sol":
rain-interpreter-interface-0.1.0/src/lib/parse/LibParseMeta.sol:5
rain-interpreter-interface-0.1.0/src/lib/codegen/LibGenParseMeta.sol:13
rainlang-0.1.2/src/lib/op/bitwise/LibOpBitwiseCountOnes.sol:9
Registry state checked 2026-08-16 by installing the newest published releases and grepping them: rain-interpreter-interface 0.1.2 carries 4 references to rain-math-binary-0.1.1, rainlang 0.1.8 carries 3, and only rain-extrospection 0.1.5 has migrated. Soldeer keys [dependencies] by package name, so both prefixes cannot be installed at once — no combination of currently published versions compiles.
The order
- This repo — bump
rain-math-binary to 0.1.3, move its version-suffixed remapping and imports, merge. Autopublish ships a new rain-interpreter-interface.
rainlang — bump both rain-math-binary and rain-interpreter-interface, merge, republish.
- The five consumers —
rain.pyth#32, rain.flare#205, rain.merkle#16, rain.erc4626.words#261, raindex#2831 — take the new versions.
Each step is one PR whose merge is human-gated like any other.
Two things not to do
Do not alias. Adding rain-math-binary-0.1.1/=dependencies/rain-math-binary-0.1.3/ compiles today and is bytecode-safe only because this particular delta is NatSpec-only, but it makes remappings.txt assert a version that is not installed, has to be repeated in five repos, and has to be unwound once this lands.
Do not drop the campaign because the payload is documentation. Ruled on rainlang#551: the versions have to move eventually, so the cascade is owed whether or not this delta carries behaviour, and deferring it only means doing the same work later under the same constraints.
For the blocked consumers
Once this issue exists, those five route to ai:blocked-on with --blocked-by rainlanguage/rainlang.interface#<this> rather than raising the same design question five times. The vetter's clearance check reads the typed ref back automatically when this closes.
Ask
Migrate
rain-interpreter-interfacetorain-math-binary0.1.3 and publish, so the consumers blocked behind it can move.This issue exists to be a typed blocker ref. Five consumer PRs are stuck and cannot route to
ai:blocked-onbecauseflag-blocked-onrefuses without a--blocked-by owner/repo#nand there was nothing to name.Why they are stuck
Consumers set
[soldeer] recursive_deps = falseand use version-suffixed remappings, so the consuming repo's ownremappings.txtmust satisfy the hard-coded imports inside its dependencies. Bumping a consumer torain-math-binary0.1.3 removes therain-math-binary-0.1.1/prefix that dependency source still hard-codes, and compilation fails.Reproduced locally under the pinned toolchain (
nix develop github:rainlanguage/rainix/53e96a7d…#sol-shell -c forge build) onrain.pyth#32, failing on three dependency files, eachimport {LibCtPop} from "rain-math-binary-0.1.1/src/lib/LibCtPop.sol":rain-interpreter-interface-0.1.0/src/lib/parse/LibParseMeta.sol:5rain-interpreter-interface-0.1.0/src/lib/codegen/LibGenParseMeta.sol:13rainlang-0.1.2/src/lib/op/bitwise/LibOpBitwiseCountOnes.sol:9Registry state checked 2026-08-16 by installing the newest published releases and grepping them:
rain-interpreter-interface0.1.2 carries 4 references torain-math-binary-0.1.1,rainlang0.1.8 carries 3, and onlyrain-extrospection0.1.5 has migrated. Soldeer keys[dependencies]by package name, so both prefixes cannot be installed at once — no combination of currently published versions compiles.The order
rain-math-binaryto 0.1.3, move its version-suffixed remapping and imports, merge. Autopublish ships a newrain-interpreter-interface.rainlang— bump bothrain-math-binaryandrain-interpreter-interface, merge, republish.rain.pyth#32,rain.flare#205,rain.merkle#16,rain.erc4626.words#261,raindex#2831— take the new versions.Each step is one PR whose merge is human-gated like any other.
Two things not to do
Do not alias. Adding
rain-math-binary-0.1.1/=dependencies/rain-math-binary-0.1.3/compiles today and is bytecode-safe only because this particular delta is NatSpec-only, but it makesremappings.txtassert a version that is not installed, has to be repeated in five repos, and has to be unwound once this lands.Do not drop the campaign because the payload is documentation. Ruled on
rainlang#551: the versions have to move eventually, so the cascade is owed whether or not this delta carries behaviour, and deferring it only means doing the same work later under the same constraints.For the blocked consumers
Once this issue exists, those five route to
ai:blocked-onwith--blocked-by rainlanguage/rainlang.interface#<this>rather than raising the same design question five times. The vetter's clearance check reads the typed ref back automatically when this closes.