Re-export mpos.lights from the top-level mpos package#1
Conversation
Every other framework follows the documented "from mpos import X" import convention (architecture/frameworks/), enforced via re-exports in mpos/__init__.py. mpos.lights (LightsManager) was the one exception -- not in the Available Frameworks list and not re-exported, forcing the submodule import the docs explicitly say to avoid. Even the Fri3d 2026 board's own init code (board/fri3d_2026.py) has to reach for `import mpos.lights as LightsManager` as a result. Adds it to the same "from . import X" + __all__ pattern already used for ui/net/audio/etc., matching the plain-module submodule-exposure style those already use (lights.py exposes module-level functions, not a class, so this mirrors that rather than the class-based singleton pattern used by AudioManager/SensorManager/etc.).
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request imports and exposes the lights submodule in the mpos package init.py file. I have no feedback to provide as there are no review comments.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
1 participant
Every other framework follows the documented "from mpos import X" import convention (architecture/frameworks/), enforced via re-exports in mpos/init.py. mpos.lights (LightsManager) was the one exception -- not in the Available Frameworks list and not re-exported, forcing the submodule import the docs explicitly say to avoid. Even the Fri3d 2026 board's own init code (board/fri3d_2026.py) has to reach for
import mpos.lights as LightsManageras a result.Adds it to the same "from . import X" + all pattern already used for ui/net/audio/etc., matching the plain-module submodule-exposure style those already use (lights.py exposes module-level functions, not a class, so this mirrors that rather than the class-based singleton pattern used by AudioManager/SensorManager/etc.).