hermes - 💡(How to fix) Fix Add a first-class plugin dependency installation seam [1 participants]

Summary

Hermes supports plugin-style memory providers, but Docker/source installs do not appear to expose a first-class way for a provider plugin to declare runtime Python dependencies that must be installed into the Hermes environment/image.

This forces external provider installers to patch the Dockerfile or manually install dependencies out-of-band.

Why this matters

A memory provider can be a clean plugin at the Python/package level but still need backend libraries such as vector stores, graph stores, database clients, or SDKs. Without a stable dependency installation seam, integrations either:

• patch Dockerfile directly;
• require users to manually run install commands after each rebuild;
• silently fail at runtime when the provider imports but its backend dependencies are absent.

That makes provider integrations harder to maintain across upstream Hermes updates.

Current behavior in vanilla Hermes

The Dockerfile installs Hermes itself:

RUN uv venv && \
    uv pip install --no-cache-dir -e ".[all]"

There is no obvious provider/plugin dependency manifest hook consumed during Docker image build or source setup.

Requested behavior

Please consider a generic plugin dependency seam, for example one of:

• a provider/plugin manifest field listing Python packages/extras;
• a requirements.txt/pyproject discovery convention for installed plugins;
• a documented build arg or install hook for runtime plugin dependencies;
• a first-class CLI command that installs provider dependencies into the active Hermes runtime.

Suggested acceptance criteria

• External memory provider dependencies can be installed without patching Hermes Dockerfile.
• Docker rebuilds include provider dependencies deterministically.
• Missing provider dependencies are visible as setup/doctor errors rather than late runtime import failures.
• The mechanism is generic for all providers/plugins, not specific to one integration.