feat: plugins install their declared Python dependencies and keep them across hermes update

[teknium1]

Directory plugins can now declare Python dependencies (pyproject.toml or manifest python_dependencies) and Hermes installs them under core constraints, refuses conflicts before install, and re-applies them after hermes update — the contract agreed with the Mnemosyne team, carved onto current main instead of waiting on #102765.

Why

python_dependencies was declare-and-surface only (#15220, #64165): a plugin's packages had to be uv pip installed into the Hermes venv by hand and were lost on every venv rebuild. Mnemosyne asked for exactly this contract in the plugin-API thread; @ethernet8023 built it inside #102765, but that PR ships a whole package manager (2,547 files) and cannot be reviewed or merged as one unit. This PR is the ~1.5k-LOC slice on today's single venv. 23 of the 105 catalog plugins already ship a pyproject.toml, so this turns their installs from "installed, won't load" into working installs.

What changes

• Install / enable / plugins update / packs / Desktop install — hermes_cli/plugin_python_deps.py reads the declaration (pyproject wins over manifest; pip_dependencies accepted as alias), drops environment-marker-excluded specs, hermes-agent self-deps and direct-URL requirements (the last are surfaced for the user), then installs through the shared tools.lazy_deps.install_specs ladder with constraints built from Hermes' own pinned dependencies and the union of every enabled peer's specs. A satisfied declaration is a no-op.
• Conflict = refusal before the tree moves into place — dry-run resolve of core + enabled peers + candidate; a conflict raises PluginOperationError naming the pins, nothing is installed, no peer is touched. --no-deps on hermes plugins install opts one install out.
• hermes update re-applies on the git, zip and both venv-repair paths (_reapply_plugin_python_dependencies), across the default home plus every live profile (custom HERMES_HOME roots included). If the union no longer resolves, each plugin is resolved alone so only culprits drop; remaining plugin-vs-plugin conflicts peel non-memory plugins first. Dropped plugins are disabled through the real config writer with a loud line naming the fix. Never blocks the update.
• python_runtime: external — sidecar-venv plugins (Mnemosyne's shape) declare it; Hermes installs nothing and they never join the union.
• hermes plugins validate / catalog CI — a plugin.yaml with no __init__.py, desktop/plugin.js or plugin.json beside it now FAILS (loadable), which is what would have caught the hollow mnemosyne-memory submission (plugin-catalog: add mnemosyne-memory #113581); declared specs must parse and be index specs (URL specs warn).
• tools.lazy_deps.install_specs gains constraints and dry_run. Loader still never installs at import time; its hint now points at hermes plugins enable <name>.
• Docs: developer-guide plugins § "Python dependencies".

Every new function is CC < 10 (ruff C901 max-complexity=9 on the new module passes; touched pre-existing functions were moved back to their origin/main complexity by extracting the new branches into helpers).

Live evidence (scratch venv + scratch HERMES_HOME, real uv, real PyPI)

Case	Result
pyproject plugin tabulate>=0.9 + pywin32; sys_platform=='win32'	installed tabulate 0.10.0, Windows-only spec skipped
manifest python_dependencies: [art>=6.0]	installed
httpx<0.20 vs core httpx==0.28.1	refused, dir absent, httpx still 0.28.1
tabulate<0.9 vs enabled peer tabulate>=0.9	refused, peer untouched
requests; this is not a marker	refused as invalid declaration
python_runtime: external + torch==99 in pyproject	nothing installed
validate: mnemosyne-memory PR tree (no __init__.py)	✗ loadable — nothing to load
uninstall tabulate+art, run re-apply	both back
edit okplugin to httpx<0.20, run re-apply	only okplugin disabled; manifestplugin (alphabetically first) kept and its deps re-applied
plugins enable on already-enabled plugin with deps removed	deps reinstalled
security.allow_lazy_installs: false	plugin installs, deps do not, message says so
Desktop path dashboard_install_plugin	deps installed, python_dependencies in result; conflict → ok: False with the same message
profile work under custom HERMES_HOME with an enabled plugin	included in re-apply union
Mnemosyne: thin wrapper (plugin.yaml kind: exclusive + __init__.py re-exporting mnemosyne_hermes + pyproject mnemosyne-hermes>=0.7,<0.8, mnemosyne-memory[embeddings]>=3.11.1)	installed, discover_memory_providers() → ('mnemosyne', available=True); after uninstalling all five packages, re-apply restores them and the provider is available again
All 23 catalog plugins with a pyproject, dry-run against core constraints	22 resolve; lancedb conflicts (requests>=2.34.2 vs core CVE pin requests==2.33.0) → will be refused from the catalog until the author relaxes it; --no-deps is the hatch. Upstream PR opened. cashew/weather have direct-URL deps → the rest install, URL ones are listed for the user

Unit: tests/hermes_cli/test_plugin_python_deps.py (2 invariants: conflicting candidate refused with peers untouched; re-apply drops only the culprit and keeps the memory provider). 39 touched test files, 587 pass.

Infographic

Credit: design and prior art @ethernet8023 (#102765 §3), contract discussion @dplush / @abdiisan (mnemosyne-oss/mnemosyne#859).

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 72a5844 — fix: read plugin-home config through the loader; register up}

debug info

CI timings

CI timings · View report · View job

Wall time 6m9s vs 6m14s (-1.3%). 3 job(s) slower, 7 faster, 3 unchanged.

• OS-specific tests / Windows-only tests: -21.0s
• Python tests / Run tests: +19.0s
• Python lints / Windows footguns (blocking): -5.0s
• Check no committed infographics / check-no-committed-infographics: -5.0s
• Profile artifact check / Reject profile archives: -3.0s

[whyyagswhy]

Independent verification on the PR head (47f8035): all three plugin suites pass locally, 24/24 on Linux (canonical runner).

Failing validation on trees with nothing loadable closes a real silent-success hole, and checking dependency declarations at validate time beats discovering them at load. No findings.