Skip to content

fix(plugins): catalog dependencies resolve without test-tool conflicts - #133451

Merged
ethernet8023 merged 2 commits into
feat/plugin-dep-quarantinefrom
feat/catalog-plugin-fixes
Oct 5, 2026
Merged

ethernet8023 merged 2 commits into
feat/plugin-dep-quarantinefrom
feat/catalog-plugin-fixes

Conversation

@ethernet8023

Copy link
Copy Markdown
Collaborator

What does this PR do?

Hermes lists available plugins in a catalog. the parent PR, #133409, blocks dependency releases less than 14 days old and checks whether catalog plugins have compatible dependencies. this PR fixes two causes of dependency-resolution failures and adds temporary exceptions for specific recent releases.

before after
a plugin has a pyproject.toml just for its linter or tests; Hermes treats it as a Python package and loses the dependencies in plugin.yaml Hermes uses [project] when present. otherwise, it reads the dependencies from the plugin manifest
a plugin's optional features or development tools conflict with Hermes's packages, even though Hermes never installs those features the copy used for installation leaves out plugin extras and development groups
a listed plugin needs a package released less than 14 days ago and cannot install under the new quarantine a dated exception admits the oldest release it accepts, without allowing newer releases

this is stacked on #133409. the changes here do not introduce the quarantine or the catalog CI job; those are in the parent PR.

Related Issue

follow-up to #133409.

credit to @fangliquanflq for the same tooling-only pyproject fix in #122164, and @webtecnica for stripping virtual members' test dependencies in #123960. the catalog run reproduced those problems across multiple entries. this branch applies the fixes to the shared install path.

Type of Change

  • bug fix
  • new feature
  • security fix
  • documentation update
  • tests
  • refactor
  • new skill

Changes Made

  1. pm/plugin_declarations.py: Hermes reads package dependencies from pyproject.toml only when it contains a [project] table. otherwise, it reads python_dependencies or pip_dependencies from the plugin manifest.
  2. pm/workspace.py: remove optional dependencies and development groups from the plugin copy used to resolve an install. the plugin repository itself is not changed. runtime dependencies and build requirements stay intact.
  3. pyproject.toml and uv.lock: add eight temporary package cutoffs. each cutoff is just after the last file upload for the oldest accepted release. comments name the affected plugins and when the regular 14-day window catches up. these lines must then be removed; a fixed date left behind would keep blocking later releases.

what's still open

this does not fix every catalog plugin. the earlier checks still found Python-version caps, incompatible runtime requirements, and mnemostack's dependency on hermes-agent itself. upstream fixes and catalog updates are separate work.

removing extras also removes optional runtime features from the install resolution, not just test tools. Hermes does not currently select plugin extras. this PR does not add a way to install those optional features.

How to Test

  1. scripts/run_tests.sh tests/pm/test_workspace.py tests/pm/test_plugin_declarations.py tests/pm/test_workspace_build_inputs.py tests/hermes_cli/test_plugin_validate.py
  2. python -m pm.build_env --source . --check-lock
  3. scripts/run-in-hermes-env python3 scripts/ci/catalog_resolve_all.py --report "$TMPDIR/catalog-fixes-report.json"

live repro: both new workspace tests fail without their corresponding fix and pass with it. they run the real package resolver and install local wheels, rather than checking source text.

check result
targeted tests at c7f8e40919 50 passed
lockfile checked using the project's specified tool versions passed
scripts/check --only health passed
13 plugins checked, covering lint-only config files, optional dependencies and conflicting torch download sources the 8 with Python dependencies resolved together without errors
8 plugins needing recent releases checked 7 resolved together; mnemostack still failed because it depends on Hermes itself

these catalog checks prove that dependency versions can resolve together. they do not prove every plugin feature works, and they do not perform a full installation of every catalog plugin. the entire catalog has not been rerun on this exact head.

Checklist

Code

  • read the contributing guide
  • commit messages follow conventional commits
  • searched for existing PRs; related fixes credited above
  • only changes related to plugin installation
  • full test suite passes — not run locally
  • python scripts/check passes — health passed; the earlier full run flagged archives in local worktrees
  • added tests and proved they fail without the fixes
  • tested on Linux / NixOS

Documentation & Housekeeping

  • comments and docstrings explain the policy and temporary cutoff removal
  • config example changes: not applicable
  • architecture/workflow instruction changes: not applicable
  • considered cross-platform behavior; dependency markers are preserved
  • tool descriptions/schemas: not applicable

Screenshots / Logs

50 tests passed, 0 failed
13 entries, 8 with Python dependencies
8 plugins lock together; 0 failing, 0 blocking

Stack

main → #133409 (quarantine and catalog check) → this PR (fixes found by that check).

Infographic

plugin dependency failures and the fixes in this PR

… block installs

The catalog-wide lock found 12 plugins that could not install for reasons
unrelated to their real dependencies:

- 6 ship a pyproject.toml holding only ruff/pytest settings, with no
  [project] table. PM treated any pyproject as the package definition,
  invented a [project] table with just a name, and uv refused it for
  lacking a version. A pyproject without [project] now leaves the plugin
  manifest in charge of dependencies.
- 4 pin pytest/ruff/ty in a dev extra or dev group, conflicting with
  core's own dev group; one pins transformers in an optional extra; two
  route torch to different PyTorch indexes through extras. Hermes never
  installs a plugin's extras, and uv syncs a member's default dev group
  into Hermes's environment, so both are dropped from the workspace copy.
…leases

Eight catalog plugins require a release younger than the 14-day window
(their own SDKs, mostly). Each gets a per-package exclude-newer cutoff at
the upload time of the oldest release the plugin accepts, so exactly that
release gets through and anything newer still waits. Every line names its
plugins and the date it becomes dead (cutoff + 14 days); the lasting fix
is upstream, an exact pin plus the plugin's own exemption.

uv.lock is relocked with the pinned uv 0.12.3, which writes the options
table in its own order.
@ethernet8023
ethernet8023 requested a review from a team as a code owner October 5, 2026 18:43
@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown

૮ >ﻌ< ა ci review

running on c7f8e40 — build: temporary quarantine cutoffs for 8 catalog plugins on

waiting for jobs to start…

@ethernet8023
ethernet8023 added this pull request to stack #133452 October 5, 2026 18:47
@ethernet8023
ethernet8023 merged commit c7f8e40 into main Oct 5, 2026
76 checks passed
@ethernet8023
ethernet8023 deleted the feat/catalog-plugin-fixes branch October 5, 2026 18:50
@alt-glitch alt-glitch added type/bug Something isn't working P3 Low — cosmetic, nice to have comp/plugins Plugin system and bundled plugins Plugin Catalog Plugin catalog entries, discovery, metadata, and catalog management labels Oct 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/plugins Plugin system and bundled plugins P3 Low — cosmetic, nice to have Plugin Catalog Plugin catalog entries, discovery, metadata, and catalog management type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants