hermes-agent: revert deprecation, fix socksio build with flit-core 4

[dot-agi]

---

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>?
• Is your test running fine brew test <formula>?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

• I did not use AI/LLM to create this PR, or I disclosed the tool/model below and reviewed its output; I did not attribute commits to AI and will answer maintainer questions and review comments myself without AI/LLM.

---

AI-assisted contribution by Claude Code (Claude Fable 5, model claude-fable-5) for ~95% of the work (CI failure diagnosis, formula change, and running the validation commands). Build, test and audit were executed by the AI on the contributor's machine; the contributor reviewed the diff, the validation output and this description.

Built and tested locally on macOS 26 (Tahoe) running arm64.

Supersedes #297271: the revert is included as a single squashed commit (Sean Molenaar credited via Co-authored-by, thanks @SMillerDev), plus the build fix that PR's CI needs.

Why that CI failed — unrelated to the revert: flit_core 4.0.1 (PyPI, 2026-08-04) removed the legacy [tool.flit.metadata] table. The socksio resource's existing patch unpins its build requirement to flit_core >=2, so PEP 517 build isolation now picks flit_core 4 and socksio 1.0.0 fails with flit_core.config.ConfigError before the wheel's requirements can even be read. socksio upstream is dormant (no release since 1.0.0, last commit 2024), so the formula caps flit_core >=2,<4 while building that resource, restoring the known-good backend (3.x) used when the 2026.8.3 bottles were built.

[p-linnane]

Please wait for discussion in #297271.

[github-actions]

@MikeMcQuaid has requested bottles to be published to this PR.

Caution

Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch.

[MikeMcQuaid]

Thanks @dot-agi!

[p-linnane]

Thanks for your contribution and patience @dot-agi!

[dot-agi]

Thank you so much @MikeMcQuaid @p-linnane and @SMillerDev!

[Nek-12]

Thanks for getting the formula undeprecated. There is a runtime packaging regression in the current 2026.8.3 bottle (confirmed on arm64_tahoe, bottle rebuild 1): all bundled plugin Python modules are present, but every plugin.yaml manifest is missing.

This can be reproduced without configuring Hermes or providing credentials:

brew fetch --force hermes-agent
bottle="$(brew --cache hermes-agent)"

# Actual: 199
tar -tzf "$bottle" \
  | grep '/libexec/lib/python3\.14/site-packages/plugins/.*\.py$' \
  | wc -l

# Actual: 0; upstream v2026.8.3 contains 96
tar -tzf "$bottle" \
  | grep '/libexec/lib/python3\.14/site-packages/plugins/.*/plugin\.ya\?ml$' \
  | wc -l

The installed-keg repro is:

prefix="$(brew --prefix hermes-agent)"
site="$($prefix/libexec/bin/python -c 'import site; print(site.getsitepackages()[0])')"

find "$site/plugins" -name '*.py' | wc -l
# 199

find "$site/plugins" \( -name 'plugin.yaml' -o -name 'plugin.yml' \) | wc -l
# 0

hermes plugins list
# No plugins installed.

This breaks bundled platform discovery. For example, with an existing Telegram configuration, the gateway starts but logs:

No adapter available for telegram
No adapter could be created for any of the 1 configured platform(s).

The Telegram implementation itself is in the bottle at plugins/platforms/telegram/{__init__,adapter,...}.py; it is simply undiscoverable because hermes_cli.plugins requires each directory plugin to contain both plugin.yaml and __init__.py.

The apparent cause is upstream packaging metadata: [tool.setuptools.packages.find] includes plugins and plugins.*, while [tool.setuptools.package-data] only includes data for hermes_cli and gateway. virtualenv_install_with_resources therefore installs the Python modules but drops the plugin manifests.

As a local verification, restoring the 96 manifests from the exact v2026.8.3 source archive made Hermes discover 55 bundled plugins, registered telegram-platform, and allowed the gateway to connect successfully.

A regression assertion around bundled plugin discovery (for example, hermes plugins list containing telegram-platform, or directly asserting that the installed Telegram manifest exists) would catch this where the current version / status / doctor formula tests do not.

[dot-agi]

@Nek-12 fixed in #297394

[wommy]

is this gonna take 2 weeks to come out or am I migrating to my docker install

[dot-agi]

is this gonna take 2 weeks to come out or am I migrating to my docker install

You mean the new PR? That's upto the maintainers to look at.