expose loguru logger to plugins via astrbot.api

[xunxiing]

将loguru导入到plugin中使用

Modifications / 改动点

astrbot/api/init.py:6,10,21 (新增)astrbot/core/log.py:420-422 (新增) exportloguru_logger viaastrbot.api full loguru API (e.g., bind(), opt(), add())

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Expose the patched loguru logger via the astrbot.api package so plugins can access the full logging API.

New Features:

• Provide a get_loguru_logger helper in the core logging module to return the patched loguru logger for external use.
• Expose a loguru_logger object from astrbot.api to make the shared logger easily available to plugins.

[sourcery-ai]

Hey - I've left some high level feedback:

• Binding loguru_logger = get_loguru_logger() at import time in astrbot.api can create initialization-order issues (e.g., before logging is configured); consider either exporting get_loguru_logger itself or using a lazily evaluated accessor instead of a module-level instance.
• To make the new API clearer and easier to type-check, add a precise return type annotation to get_loguru_logger() (e.g., the loguru.Logger type) and, if feasible, re-export that type for plugin authors.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Binding `loguru_logger = get_loguru_logger()` at import time in `astrbot.api` can create initialization-order issues (e.g., before logging is configured); consider either exporting `get_loguru_logger` itself or using a lazily evaluated accessor instead of a module-level instance.
- To make the new API clearer and easier to type-check, add a precise return type annotation to `get_loguru_logger()` (e.g., the `loguru.Logger` type) and, if feasible, re-export that type for plugin authors.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request introduces a get_loguru_logger function to the core logging module and exposes it through the public API for plugin use. Feedback suggests that the function should return a logger instance bound with a [Plug] tag to ensure plugin logs are correctly categorized, rather than defaulting to the core tag. Additionally, the reviewer requested the inclusion of unit tests for this new functionality.

[gemini-code-assist]

The get_loguru_logger function currently returns the base patched logger, which defaults the plugin_tag to [Core] in the _patch_record logic (line 84). Since this function is explicitly intended for plugin use, it should return a logger instance bound with the [Plug] tag. This ensures that logs generated by plugins using this API are correctly categorized in the output, while still allowing plugins to override the tag if necessary using .bind(). As this introduces new behavior for plugin logging, please include a corresponding unit test.

Suggested change

	def get_loguru_logger():
	"""Returns the patched loguru logger for plugin use."""
	return _loguru
	def get_loguru_logger():
	"""Returns the patched loguru logger for plugin use."""
	return _loguru.bind(plugin_tag="[Plug]")

References

1. New functionality should be accompanied by corresponding unit tests.