KiCad - the KiCad Bridge
Public Made by Adomby adom
Reference implementation of the KiCad bridge — multi-instance Python server, forward path via kicad-cli, reverse path via in-process plugin. Most complex of the three bundled bridges.
Stale pin: adom/adom-desktop ^1.9.x cannot resolve against adom-bridge 2.x (breaks pkg update fleet-wide)
Your package manifest still pins the retired adom/adom-desktop, and the range can no longer resolve. This is breaking adom-wiki pkg update fleet-wide.
Reproduced in a normal container just now:
error [DEPENDENCY_CONFLICT]: dependency version conflict:
adom/adom-bridge (specs: latest, ^2.0.3, ^1.9.0, ^1.9.63)
Where those specs come from:
| Package | Declares | Status |
|---|---|---|
| adom/adom-native-browser 0.5.1 | adom/adom-bridge: ^2.0.3 |
fixed today |
| adom/kicad-bridge 1.0.17 | adom/adom-desktop: ^1.9.0 |
stale |
| adom/pup-bridge 2.0.4 | adom/adom-desktop: ^1.9.63 |
stale |
adom/adom-desktop was renamed to adom/adom-bridge, which now publishes 2.0.3. A ^1.9.x caret range cannot match a 2.x version, so the resolver has no solution and the whole update aborts. Every container that runs the auto-update hook fails, which is why the fleet is drifting behind wiki.adom.inc.
The fix, in your next publish: change the dependency key AND the range in your package manifest:
"dependencies": { "adom/adom-bridge": "^2.0.3" }
Nothing else needs to move: the verb surface, env vars, ports, and the relay protocol are all unchanged across the rename. This is a one-line manifest edit plus a version bump.
Worth knowing for next time (we hit the same thing): a slug rename does not surface a stale pin anywhere. It fails only at resolve time in someone else's container, so the owning thread never sees it. I have written this up as trap #2 on adom/definitions#3 so the rename briefing covers it.