deprecate ready setting

[JarbasAl]

companion to https://github.com/OpenVoiceOS/ovos-config/pull/166

NOTES:

• to check if a service is ready, this should be used https://github.com/OpenVoiceOS/ovos-utils/blob/dev/ovos_utils/process_utils.py#L124
• now that skills are not necessarily managed by core, mycroft.ready message was emitted almost randomly and was not dependendable on
• mycroft.ready is redefined by this PR as "core is ready to register intents", vs "everything finished loading"
• external skills / anything registering intents should still use mycroft.ready in combination with ProcessUtils linked above to determine when to load

[NeonDaniel]

Why deprecate this? It is used in many skills and integrations to determine when core services are ready for normal usage

[JarbasAl]

discussion here https://matrix.to/#/!EOygeDJPfJQOfNacqH:matrix.org/$cN3qQ_K_CdrMSYXUx3rDRUGs60gwX3Q_QlK3vzeEkIo?via=matrix.org&via=tchncs.de&via=mozilla.org

[JarbasAl]

Why deprecate this? It is used in many skills and integrations to determine when core services are ready for normal usage

edited original post to include some extra info about this

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 40.00000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 76.43%. Comparing base (23f0bab) to head (a8e6fdc). Report is 28 commits behind head on dev.

Files with missing lines	Patch %	Lines
ovos_core/skill_manager.py	40.00%	9 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #554      +/-   ##
==========================================
+ Coverage   75.33%   76.43%   +1.09%     
==========================================
  Files          15       15              
  Lines        3094     1553    -1541     
==========================================
- Hits         2331     1187    -1144     
+ Misses        763      366     -397     

Flag	Coverage Δ
end2end	56.27% <40.00%> (?)
unittests	54.08% <40.00%> (-21.26%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[coderabbitai[bot]]

Walkthrough

The changes in this pull request enhance the skill management functionality within the ovos_core module. Key updates include the removal of the deprecated load_priority, is_device_ready, handle_check_device_readiness, and check_services_ready methods. The run method has been improved for skill loading, and refinements have been made to methods handling network dependencies. Unit tests for the SkillManager class have been updated, including the removal of certain tests and adjustments to existing ones for better coverage and logging. Additionally, the workflow for coverage reporting has been streamlined.

Changes

File Path	Change Summary
ovos_core/skill_manager.py	- Added imports for SKILL_MAIN_MODULE, SkillLoader, and PluginSkillLoader. - Deprecated and removed load_priority, is_device_ready, handle_check_device_readiness, and check_services_ready methods. - Updated run method to remove wait_for_internet logic. - Refined _load_on_network and _load_on_internet methods with added logging. - Adjusted GUI connection handling for skills.
test/unittests/skills/test_manager.py	- Removed test_handle_check_device_readiness method. - Expanded test_load_new_skills_with_blacklisted_skill method with logging assertions.
test/unittests/skills/test_skill_manager.py	- Altered test_instantiate method to comment out the 'mycroft.skills.initialized' event handler.
requirements/skills-audio.txt	- Updated version constraint for ovos-skill-boot-finished from >=0.1.0,<1.0.0 to >=0.2.0,<1.0.0.
.github/workflows/coverage.yml	- Updated test dependency installation path. - Streamlined coverage report generation by removing specific installations and focusing on broader coverage.

Possibly related PRs

• #555: The changes in ovos_core/skill_manager.py regarding skill loading processes and the introduction of a new attribute _detected_installed_skills are directly related to the modifications made in the same file in the main PR, which also focuses on enhancing skill management and loading logic.

Suggested labels

refactor, fix

Suggested reviewers

• goldyfruit
• j1nx
• builderjer

Poem

In the burrow of code, changes hop,
Skills now load with a skip and a bop.
Old methods fade, new paths we trace,
With tests that ensure a smoother space.
So here's to the tweaks that make us cheer,
For a brighter skill future, let’s give a cheer! 🐇✨

---

📜 Recent review details

Configuration used: CodeRabbit UI Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between c2d740232961c0b9a89cc356ac636e2a7e896d09 and fa1d498cf626bacf92e15894cf94308005a002a8.

📒 Files selected for processing (4)

• ovos_core/skill_manager.py (7 hunks)
• requirements/skills-audio.txt (1 hunks)
• test/unittests/test_manager.py (0 hunks)
• test/unittests/test_skill_manager.py (1 hunks)

💤 Files with no reviewable changes (1)

• test/unittests/test_manager.py

🧰 Additional context used

🔇 Additional comments (4)

requirements/skills-audio.txt (1)

2-2: LGTM! Verify compatibility with the new minimum version.

The update to the version constraint for ovos-skill-boot-finished (from >=0.1.0,<1.0.0 to >=0.2.0,<1.0.0) aligns with the PR objectives of moving the mycroft.ready message to a skill. This change ensures that the latest implementation of the boot finished functionality is used.

To ensure compatibility, please verify that version 0.2.0 of ovos-skill-boot-finished is available and stable. You can use the following script to check:

This script will help ensure that the new minimum version is available, stable, and doesn't have any recent critical issues.

test/unittests/test_skill_manager.py (1)

Line range hint 1-278: Overall assessment of changes to test_skill_manager.py

The modification to the test_instantiate method is the only change in this file and aligns well with the PR objectives. The removal of the 'mycroft.skills.initialized' event from the expected results reflects the intended change in how readiness is determined in the system.

The change is minimal and focused, which reduces the risk of unintended side effects. However, it's crucial to ensure that this change is properly documented and communicated to developers who might be relying on the old behavior.

To ensure the change doesn't break existing functionality:

1. Run the full test suite to confirm that all other tests pass.
2. Verify that the SkillManager class in the main codebase has been updated to reflect this change in behavior.

#!/bin/bash
# Run the test suite
python -m unittest discover test/unittests

# Check for any remaining references to 'mycroft.skills.initialized' in the SkillManager class
rg "mycroft\.skills\.initialized" --type python ovos_core/skill_manager.py

ovos_core/skill_manager.py (2)

Line range hint 1-824: Overall assessment of changes

The modifications to the SkillManager class align well with the PR objectives and generally improve the skill management process. Key improvements include:

1. Deprecation of methods related to the old mycroft.ready message usage.
2. Enhanced network and connection handling.
3. Improved skill loading processes with better support for plugin skills and local replacements.

While there are some areas for potential improvement (such as configurable paths and handling of external skills), the overall changes are well-implemented and should lead to more robust skill management.

---

Line range hint 209-233: Verify impact of deprecated methods

The following methods have been deprecated and simplified:

• is_device_ready
• handle_check_device_readiness
• check_services_ready
• load_priority

While this aligns with the PR objectives to redefine the usage of the mycroft.ready message, it's important to ensure that no other parts of the system still rely on the previous functionality of these methods.

To check for potential issues, run the following script:

Also applies to: 392-394

✅ Verification successful

Deprecated Methods Usage Verified

The deprecated methods is_device_ready, handle_check_device_readiness, check_services_ready, and load_priority are exclusively used within ovos_core/skill_manager.py. No external usage detected, ensuring safe deprecation.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usage of deprecated methods in the codebase
echo "Searching for usage of deprecated methods:"
rg -n "is_device_ready|handle_check_device_readiness|check_services_ready|load_priority" --type python

Length of output: 230

---

Script:

#!/bin/bash
# Search for usage of deprecated methods in the codebase
echo "Searching for usage of deprecated methods:"
rg -n "is_device_ready|handle_check_device_readiness|check_services_ready|load_priority" --type py

Length of output: 479

---

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?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

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)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[NeonDaniel]

discussion here https://matrix.to/#/!EOygeDJPfJQOfNacqH:matrix.org/$cN3qQ_K_CdrMSYXUx3rDRUGs60gwX3Q_QlK3vzeEkIo?via=matrix.org&via=tchncs.de&via=mozilla.org

I have used it in Neon without changes for probably more than a year now; changes to default configuration could be an alternative solution compared to removing configuration support completely.

If the meaning of "mycroft.ready" is changing here, I would ask that this emit something less ambiguous (maybe "mycroft.intent_service.ready", or implement ProcessStatus directly for consistency with other modules that report state. mycroft.ready emit should be configurable (possibly with a deprecation warning) since the meaning of the event has changed; this would allow anyone wanting to restore backwards-compat. to emit that message with a plugin (i.e. the React GUI might want to wait for the GUI core service to start).

[JarbasAl]

moved message to skill https://github.com/OpenVoiceOS/skill-ovos-boot-finished/pull/15

since this is in requirements this is no longer a breaking change, just an optional component