Background
PR #214 was merged as a hotfix for the mdr.inference import cycle by deferring the TaskStep import in refiner.pipeline.planning.
That fixes the immediate failure, but the underlying design smell remains: inference and robotics built-ins import describe_builtin from refiner.pipeline.planning, even though describe_builtin is just metadata/decorator plumbing. Importing the planner should not be required to tag a callable as a Refiner built-in.
The failure path that motivated the hotfix was roughly:
mdr.inference
-> refiner.inference.generate_text
-> refiner.pipeline.planning
-> refiner.pipeline.sources.task
-> refiner.pipeline.sources.__init__
-> refiner.pipeline.sources.readers
-> refiner.pipeline.sources.readers.lerobot
-> refiner.robotics.motion
-> refiner.pipeline.planning.describe_builtin
At that point planning.py was partially initialized, so describe_builtin was not available yet.
Proposed direction
Extract built-in metadata helpers out of refiner.pipeline.planning into a dependency-light module, for example:
refiner.pipeline.builtins
That module could own:
_REFINER_BUILTIN_CALL_ATTR
describe_builtin(...)
- possibly shared helpers for reading/parsing built-in metadata, if useful
Then update built-in producers/consumers to import from the lightweight module instead of duplicating the attr string or importing the planner:
refiner.inference.generate_text
refiner.robotics.motion
refiner.robotics.hand_tracking
refiner.inference.internal.runtime
refiner.services.discovery
refiner.platform.manifest
refiner.pipeline.planning
For compatibility, refiner.pipeline.planning can continue re-exporting describe_builtin for one release cycle, but it should no longer be the ownership location.
Acceptance criteria
- Importing
mdr.inference in a fresh Python process succeeds.
- Inference and robotics built-ins do not import
refiner.pipeline.planning just to access describe_builtin.
- The built-in metadata attribute name is centralized instead of duplicated across modules.
- Existing callers of
from refiner.pipeline.planning import describe_builtin either keep working via a documented compatibility re-export or have a deliberate migration path.
- Regression coverage uses a subprocess import test so partial-initialization cycles are not hidden by pytest import order.
Suggested regression:
subprocess.run(
[sys.executable, "-c", "import refiner as mdr; mdr.inference"],
check=True,
)
Background
PR #214 was merged as a hotfix for the
mdr.inferenceimport cycle by deferring theTaskStepimport inrefiner.pipeline.planning.That fixes the immediate failure, but the underlying design smell remains: inference and robotics built-ins import
describe_builtinfromrefiner.pipeline.planning, even thoughdescribe_builtinis just metadata/decorator plumbing. Importing the planner should not be required to tag a callable as a Refiner built-in.The failure path that motivated the hotfix was roughly:
At that point
planning.pywas partially initialized, sodescribe_builtinwas not available yet.Proposed direction
Extract built-in metadata helpers out of
refiner.pipeline.planninginto a dependency-light module, for example:That module could own:
_REFINER_BUILTIN_CALL_ATTRdescribe_builtin(...)Then update built-in producers/consumers to import from the lightweight module instead of duplicating the attr string or importing the planner:
refiner.inference.generate_textrefiner.robotics.motionrefiner.robotics.hand_trackingrefiner.inference.internal.runtimerefiner.services.discoveryrefiner.platform.manifestrefiner.pipeline.planningFor compatibility,
refiner.pipeline.planningcan continue re-exportingdescribe_builtinfor one release cycle, but it should no longer be the ownership location.Acceptance criteria
mdr.inferencein a fresh Python process succeeds.refiner.pipeline.planningjust to accessdescribe_builtin.from refiner.pipeline.planning import describe_builtineither keep working via a documented compatibility re-export or have a deliberate migration path.Suggested regression: