hermes - 💡(How to fix) Fix Track upstream lark-oapi pkg_resources warning/crash in Feishu adapter

Summary

Hermes' Feishu/Lark platform depends on lark-oapi==1.5.3 via the feishu extra and the lazy dependency entry platform.feishu. That SDK version imports pkg_resources.declare_namespace() from lark_oapi/ws/pb/google/__init__.py, which emits a startup warning today and is expected to become a hard failure when pkg_resources.declare_namespace is unavailable in newer setuptools environments.

This is primarily an upstream lark-oapi bug, but it is visible to Hermes users who enable Feishu, so Hermes should track it and update once a fixed lark-oapi release is available.

User-visible warning

.../site-packages/lark_oapi/ws/pb/google/__init__.py:2: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.
  __import__('pkg_resources').declare_namespace(__name__)

Verification

I checked the latest released lark-oapi package before filing this issue:

lark-oapi==1.6.5
lark_oapi/ws/pb/google/__init__.py:
try:
    __import__('pkg_resources').declare_namespace(__name__)
except ImportError:
    __path__ = __import__('pkgutil').extend_path(__path__, __name__)

Hermes currently pins Feishu to lark-oapi==1.5.3 in both:

• pyproject.toml (feishu extra)
• tools/lazy_deps.py (LAZY_DEPS["platform.feishu"])

Upstream status

Existing upstream reports/fix, so Hermes should not duplicate the root-cause PR:

• larksuite/oapi-sdk-python#108 — warning report
• larksuite/oapi-sdk-python#115 — future/current AttributeError report
• larksuite/oapi-sdk-python#124 — open PR replacing pkg_resources with pkgutil.extend_path

The upstream PR appears to be the correct minimal fix: the existing generated code already falls back to pkgutil.extend_path when pkg_resources is absent, and PR #124 makes that path unconditional.

Suggested Hermes resolution

Once lark-oapi releases a version containing the upstream fix:

1. Bump Hermes' Feishu pin in pyproject.toml.
2. Bump the matching lazy dependency pin in tools/lazy_deps.py.
3. Regenerate uv.lock.
4. Smoke-test importing/starting the Feishu adapter with warnings treated as errors for this class of warning.

Until then, a local Hermes code workaround would likely be less desirable than tracking the upstream fix, because the warning/failure originates inside SDK package import code.