feat!: config file + dynamic plugins #30
Conversation
|
Warning Rate limit exceeded@JarbasAl has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 10 minutes and 49 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThis pull request introduces significant changes to the HiveMind Core project, focusing on enhancing modularity, configuration management, and simplifying protocol handling. The modifications span across multiple files, including Changes
Sequence DiagramsequenceDiagram
participant User
participant ConfigManager
participant ServiceInitializer
participant ProtocolFactory
participant HiveMindService
User->>ConfigManager: Request server configuration
ConfigManager-->>User: Return configuration
User->>ServiceInitializer: Initialize service
ServiceInitializer->>ProtocolFactory: Get protocols
ProtocolFactory-->>ServiceInitializer: Return protocol classes
ServiceInitializer->>HiveMindService: Create service instance
HiveMindService->>HiveMindService: Configure and run
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (7)
hivemind_core/database.py (1)
12-20: Consider validating config keys before usage
While this refactor simplifies setup by retrieving the database backend from config, the code assumes"module"is always present inconfig["database"]. If “module” is missing or ifconfig.get(name, {})doesn't match expectations, it could lead to runtime errors. Adding a fallback or explicit error logging for missing keys would improve robustness.hivemind_core/config.py (1)
28-36: Graceful configuration file creation
Merging_DEFAULTinto a fresh config ensures the user always has valid defaults. If partial updates or advanced merges are needed later, consider deeper merges or version checks.hivemind_core/protocol.py (1)
192-192: [Optional] Validate external dictionary usage forclients.
The attributeclients = {}is declared at the class level but also used in instance methods. If multiple protocol instances are created, they might share state unintentionally. Consider whether this should be an instance attribute.README.md (4)
136-136: Consider removing the$or showing command output to silence MD014.-$ hivemind-core listen +hivemind-core listen🧰 Tools
🪛 Markdownlint (0.37.0)
136-136: null
Dollar signs used before commands without showing output(MD014, commands-show-output)
206-206: Same MD014 consideration for “$ hivemind-core add-client” usage.-$ hivemind-core add-client ... +hivemind-core add-client ...🧰 Tools
🪛 Markdownlint (0.37.0)
206-206: null
Dollar signs used before commands without showing output(MD014, commands-show-output)
220-220: Again, consider removing the$or showing sample output for the list command.🧰 Tools
🪛 Markdownlint (0.37.0)
220-220: null
Dollar signs used before commands without showing output(MD014, commands-show-output)
344-344: Remove the$or show command output as with prior commands.🧰 Tools
🪛 Markdownlint (0.37.0)
344-344: null
Dollar signs used before commands without showing output(MD014, commands-show-output)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
README.md(11 hunks)hivemind_core/__main__.py(1 hunks)hivemind_core/config.py(1 hunks)hivemind_core/database.py(1 hunks)hivemind_core/protocol.py(6 hunks)hivemind_core/scripts.py(13 hunks)hivemind_core/service.py(3 hunks)requirements.txt(1 hunks)
🧰 Additional context used
🪛 Ruff (0.8.2)
hivemind_core/protocol.py
215-215: Do not use bare except
(E722)
220-220: Do not use bare except
(E722)
281-281: Do not use bare except
(E722)
286-286: Do not use bare except
(E722)
308-308: Do not use bare except
(E722)
313-313: Do not use bare except
(E722)
333-333: Do not use bare except
(E722)
338-338: Do not use bare except
(E722)
🪛 LanguageTool
README.md
[uncategorized] ~54-~54: The abbreviation “e.g.” (= for example) requires two periods.
Context: ...hat to do you the received binary data, eg. process incoming audio. Each component...
(E_G)
🪛 Markdownlint (0.37.0)
README.md
136-136: null
Dollar signs used before commands without showing output
(MD014, commands-show-output)
206-206: null
Dollar signs used before commands without showing output
(MD014, commands-show-output)
220-220: null
Dollar signs used before commands without showing output
(MD014, commands-show-output)
344-344: null
Dollar signs used before commands without showing output
(MD014, commands-show-output)
🔇 Additional comments (56)
hivemind_core/database.py (1)
5-6: Imports for configuration and database factory look appropriate
This new approach centralizes configuration handling via get_server_config() and adds flexibility for different database modules. No issues spotted here.
hivemind_core/service.py (10)
2-8: Refined imports
Using Callable, Optional, Type from the typing module and pulling in get_server_config() aligns well with this file’s expanded scope for configurable protocols.
14-18: Agent protocol retrieval
The get_agent_protocol function delegates retrieval to a plugin factory. This is a clear approach that helps keep agent logic decoupled from the service.
20-24: Network protocol retrieval
Same pattern as the agent protocol. Code is consistent and straightforward.
26-32: Optional binary protocol
Returning a dummy fallback if module is None nicely handles the absence of a binary protocol. This design choice is clean and avoids unwanted exceptions.
36-36: Updated service logs
Renaming log messages for "hivemind-core" ensures consistent branding and clarity.
Also applies to: 40-40, 44-44, 48-48, 52-52
99-99: Service set_alive call
Ensuring the service status is set to “alive” immediately after instantiation is aligned with the ProcessStatus usage.
102-103: Transition to started status
This signals that initialization is proceeding. The usage is consistent with the rest of the status flow.
105-106: Agent protocol instantiation
Passing a dedicated config object into the factory’s protocol class is a good step toward plugin autonomy. This clarifies the boundary between the HiveMind core and plugin logic.
Also applies to: 108-108
112-115: Binary protocol support
The optional binary protocol is instantiated here, bridging agent protocol objects if configured. This design keeps agent/binary responsibilities neatly separated.
125-126: Network protocol construction
The same pattern ensures consistency: fetch class + config from get_network_protocol(). Easy to follow, and the logging of network_class.__name__ helps with debugging.
Also applies to: 128-128
hivemind_core/__main__.py (1)
5-5: Simplified instantiation
Constructing HiveMindService() with no extra arguments enforces the new centralized configuration approach. This streamlines usage and eliminates repeated CLI arguments.
hivemind_core/config.py (1)
7-27: Centralized default configuration
Defining _DEFAULT sets a clear baseline for protocols and database modules. This is an effective way to ensure minimal required configuration, particularly for newbies or quick setups.
hivemind_core/scripts.py (13)
8-8: Consolidated imports
Pulling ClientDatabase and HiveMindService into these scripts reflects the new design of simpler commands, each backed by a default config.
57-57: Function signature for add_client
Removed backend arguments align with the new config-based approach. The function remains simpler for end users.
76-76: Database usage
Instantiating ClientDatabase() within a context manager is clean. Logging db.db.__class__.__name__ is also helpful for debugging which plugin is active.
103-104: rename_client function
No more database-specific arguments. This is consistent with the PR’s shift to config-driven usage. The logic remains straightforward.
115-115: delete_client function
Again, usage of the default ClientDatabase() is aligned with the new approach. The function’s code effectively revokes credentials.
Also applies to: 117-118
136-136: list_clients
Lists the table of client data from the default config-based database. Good usage of rich for user-friendly CLI output.
Also applies to: 145-145
160-161: listen
Eliminating many CLI options in favor of a single HiveMindService instantiation drastically simplifies command usage.
168-169: allow_msg
Default database usage. The flow for toggling allowed message types remains understandable, with a short path to success or exit.
185-186: blacklist_msg
Reuses the same approach as allow_msg. The code is consistent, straightforward, and uses the new config system.
202-203: blacklist_skill
Same pattern of removing the DB arguments. The logic to append new skill IDs to the skill blacklist remains intact.
220-221: unblacklist_skill
Allows removing items from a client’s skill blacklist with a simpler database approach.
237-238: blacklist_intent
Similar changes as skill blacklisting. This keeps the code consistent throughout the script.
254-255: unblacklist_intent
Removes an intent ID from the blacklist without referencing any DB-specific CLI arguments.
hivemind_core/protocol.py (1)
26-26: [Optional] Check for references to ClientCallbacks usage.
The new import for ClientCallbacks looks correct. Ensure any references to it are consistent and do not require further changes in the calling code.
requirements.txt (1)
9-12: Ensure compatibility with updated versions.
The bumped versions (hivemind-plugin-manager>=0.3.0,<1.0.0, ovos-bus-client>=1.3.1,<2.0.0, json-database>=0.9.1,<1.0.0) look fine. Confirm that the new package versions are tested with your codebase, especially for any potential breaking changes.
README.md (28)
3-6: Nice introduction to satellites.
These lines effectively explain satellites and central hub roles. The language is clear and user-friendly.
8-12: Scalable environment overview looks good.
The mention of hub-to-hub connections for advanced setups is beneficial.
13-15: Clarify adaptation beyond OVOS.
It’s great that the text highlights adaptability to various AI backends. No changes needed.
16-17: Useful reference to YouTube channel.
Good addition to direct users to demonstrations.
23-30: Key features look consistent with the new architecture.
No issues detected.
46-50: Clear coverage of the architecture.
The high-level description of the key protocol components is thorough.
51-57: Database plugin mention is aligned with broader plugin design.
No major concerns.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~54-~54: The abbreviation “e.g.” (= for example) requires two periods.
Context: ...hat to do you the received binary data, eg. process incoming audio. Each component...
(E_G)
58-65: Config file approach nicely reduces CLI overhead.
Implementation notes look consistent.
66-96: JSON config example is well structured.
Ensure version control or environment documentation clarifies how to override these defaults.
99-100: Separation with horizontal rule is good for readability.
No issues.
101-101: Command-line introduction is concise.
Looks good.
112-112: “Adding a Satellite” heading is straightforward.
No issues.
114-114: Database mention for add-client usage.
Clear example demonstrating the new CLI usage.
129-129: Security note is helpful.
Reminding users about the credentials is essential.
141-152: Plugin overview table is concise and informative.
Great introduction to available plugin categories.
153-163: Client overview is comprehensive.
No concerns.
210-211: Reiterating usage scenario is helpful.
No changes needed.
224-225: Use-cases for listing clients are clear.
No issues.
266-267: Expanding the explanation of allow-msg usage is beneficial.
No concerns.
280-281: blacklist-msg usage is clearly documented.
Good job explaining typical use cases.
294-295: Clear example for blacklist-skill.
No issues.
321-322: Intent blocking usage is well-documented.
No issues.
348-349: Straightforward instructions for listen usage.
No changes necessary.
358-358: Heading for next steps is helpful.
No issues.
360-362: Links to docs and chat are valuable.
368-369: Encourages open source collaboration.
No issues.
381-382: Matrix discussion pointer is relevant.
No changes needed.
384-396: Good callout for beginner-friendly projects.
Inviting community support fosters faster growth.
| ## 🔌 Modular Design with Plugins | ||
|
|
||
| HiveMind is designed to be modular, allowing you to customize its behavior through plugins managed by the **HiveMind | ||
| Plugin Manager**. | ||
|
|
||
| - 📚 **Documentation**: [HiveMind Docs](https://jarbashivemind.github.io/HiveMind-community-docs) | ||
| - 💬 **Chat**: Join the [HiveMind Matrix Chat](https://matrix.to/#/#jarbashivemind:matrix.org) for news, support, and | ||
| discussion. | ||
| - **Transport Mechanism** 🚚: The protocol does not specify **how** messages are transported; this is implemented via **network protocol plugins**. | ||
| - **Payload Handling** 🤖 : The protocol does not dictate **who** handles the messages; this is implemebted via **agent protocol plugins**. | ||
| - **Message Format** 📦: The protocol supports **JSON data** modeled after the `Message` [structure from OVOS](https://jarbashivemind.github.io/HiveMind-community-docs/13_mycroft/) and **binary** data; what happens to the received binary data is implemented via **binary data protocol plugins**. | ||
| - **Database**: 🗃️ how client credentials are stored is implemented via **database plugins** |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix typo “implemebted” → “implemented”.
- The protocol does not dictate **who** handles the messages; this is implemebted via **agent protocol** plugins.
+ The protocol does not dictate **who** handles the messages; this is implemented via **agent protocol** plugins.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## 🔌 Modular Design with Plugins | |
| HiveMind is designed to be modular, allowing you to customize its behavior through plugins managed by the **HiveMind | |
| Plugin Manager**. | |
| - 📚 **Documentation**: [HiveMind Docs](https://jarbashivemind.github.io/HiveMind-community-docs) | |
| - 💬 **Chat**: Join the [HiveMind Matrix Chat](https://matrix.to/#/#jarbashivemind:matrix.org) for news, support, and | |
| discussion. | |
| - **Transport Mechanism** 🚚: The protocol does not specify **how** messages are transported; this is implemented via **network protocol plugins**. | |
| - **Payload Handling** 🤖 : The protocol does not dictate **who** handles the messages; this is implemebted via **agent protocol plugins**. | |
| - **Message Format** 📦: The protocol supports **JSON data** modeled after the `Message` [structure from OVOS](https://jarbashivemind.github.io/HiveMind-community-docs/13_mycroft/) and **binary** data; what happens to the received binary data is implemented via **binary data protocol plugins**. | |
| - **Database**: 🗃️ how client credentials are stored is implemented via **database plugins** | |
| ## 🔌 Modular Design with Plugins | |
| HiveMind is designed to be modular, allowing you to customize its behavior through plugins managed by the **HiveMind | |
| Plugin Manager**. | |
| - **Transport Mechanism** 🚚: The protocol does not specify **how** messages are transported; this is implemented via **network protocol plugins**. | |
| - **Payload Handling** 🤖 : The protocol does not dictate **who** handles the messages; this is implemented via **agent protocol plugins**. | |
| - **Message Format** 📦: The protocol supports **JSON data** modeled after the `Message` [structure from OVOS](https://jarbashivemind.github.io/HiveMind-community-docs/13_mycroft/) and **binary** data; what happens to the received binary data is implemented via **binary data protocol plugins**. | |
| - **Database**: 🗃️ how client credentials are stored is implemented via **database plugins** |
dynamically load available plugins
move to config file instead of overcomplicating cli arguments
Summary by CodeRabbit
Release Notes for HiveMind Core
Documentation
Configuration
Dependency Updates
Code Refactoring
Service Improvements