I'm running the agent using the official docker image and hindsight in another container (local external) and can't find a way to get hindsight-client to install on boot. Hoping this solves it.

Thanks for working on this. I wanted to add a data point from an immutable container/Kubernetes deployment use case, because this is a real packaging problem for us.

We run Hermes as a derived container image built from nousresearch/hermes-agent:<tag> and then deploy that image into Kubernetes. In that model, dependencies for supported features need to be present at image build time rather than installed after startup.

Our current workaround is to bake hindsight-client into the wrapper image explicitly:

FROM nousresearch/hermes-agent:v2026.4.8

RUN python3 -m pip install --no-cache-dir --break-system-packages "hindsight-client==0.5.0"

That has worked well for us. It makes hindsight support reproducible and keeps restarts and rollbacks predictable.

From our perspective, the important requirement is:

If memory.provider = hindsight is part of the supported container story, there should be a supported way to build an image where hindsight-client is already present before the container starts.

Why this matters for us:

• We do not want to rely on runtime pip install in a running container.
• We want the image artifact itself to describe the full dependency set.
• We want restart behavior to be independent of writable runtime state or manual operator changes.
• This is especially important in Kubernetes and other environments with ephemeral runtime filesystems.

I do not have a strong opinion on whether the right answer is this PR specifically (it seems to be slightly incomplete?) or some adjacent packaging change, but I do want to confirm that the underlying problem is real and that a solution for build-time inclusion would solve it cleanly for our deployment model.

This looks related to support thread: "Hermes Docker does not contain hindsight pip package" in discord
https://discord.com/channels/1053877538025386074/1494880345915654246/1494880345915654246

Ok. I just went ahead and regenerated the uv lock and commited on top of a more recent commit. In terms of it being incomplete, this is all I need to unblock what I am trying to do, but happy to look at other stuff that would need to happen if I'm missing anything

@jbotwell Why did this get closed?

@descention , It was waiting for a maintainer review for a long time, and in the meantime they added a services.hermes-agent.extraPythonPackages option that allows nix people to include Python packages declaratively without needing to be in container mode. I figured that was going to be the preferred way to do it and I interpreted the maintainer review lag as reluctance to put that dependency in the pyproject. All that said, I'm happy to reopen it if you think it makes sense

@jbotwell I'd prefer to see it natively supported. I don't like having to manually add additional packages to use built-in features. Your PR addresses that well.

Cool. Should be good to go again? It'll keep getting into conflicts with uv.lock, though. Easy to fix, but heads-up that that divergence is a thing

@alt-glitch can you take a look at this one?

Putting hindsight-client into the [all] extra means every user doing pip install 'hermes-agent[all]' pulls hindsight-client in, even though the vast majority aren't using hindsight as their memory provider. We'd rather not require it in everyone's install just to fix the NixOS build path.

Would prefer to keep the hindsight extra itself (that's the right fix for #8873 — packagers can opt in at build time), but drop it from [all]. NixOS/uv2nix/Docker users who want hindsight can add [hindsight] to their own extras list. Same pattern we use for modal, daytona, vercel, rl, yc-bench — present as extras, absent from [all].

@teknium1 , this is all:

all = [
  "hermes-agent[modal]",
  "hermes-agent[daytona]",
  "hermes-agent[vercel]",
  "hermes-agent[messaging]",
  # matrix: python-olm (required by matrix-nio[e2e]) is upstream-broken on
  # modern macOS (archived libolm, C++ errors with Clang 21+).  On Linux the
  # [matrix] extra's own marker pulls in the [e2e] variant automatically.
  "hermes-agent[matrix]; sys_platform == 'linux'",
  "hermes-agent[cron]",
  "hermes-agent[cli]",
  "hermes-agent[dev]",
  "hermes-agent[tts-premium]",
  "hermes-agent[slack]",
  "hermes-agent[pty]",
  "hermes-agent[hindsight]",
  "hermes-agent[honcho]",
  "hermes-agent[mcp]",
  "hermes-agent[homeassistant]",
  "hermes-agent[sms]",
  "hermes-agent[acp]",
  "hermes-agent[voice]",
  "hermes-agent[dingtalk]",
  "hermes-agent[feishu]",
  "hermes-agent[google]",
  "hermes-agent[mistral]",
  "hermes-agent[bedrock]",
  "hermes-agent[web]",
]

modal, daytona, and vercel are in all. There seem to be a number of packages in there that are only likely to be useful for a subset of users. I mean, I agree it would make sense to have packages that are declarable on their own without having to pull in a whole universe of packages but I'm a little fuzzy on the criteria for a package being in that list, though. Currently I'm grabbing hindsight by just declaring its build in my nix config and putting it in extraPythonPackages (which is super useful, so I'm glad that was added). I don't think there's a way to declare which pyproject dependency groups are passed to the virtual environment in nix, though, is there? As per a conversation with hermes:

Yes, the infrastructure is there but it's not wired through. Here's what I found:

nix/python.nix already accepts dependency-groups ? [ "all" ] and passes it to mkVirtualEnv:

pythonSet.mkVirtualEnv "hermes-agent-env" {
  hermes-agent = dependency-groups;
}

But nix/hermes-agent.nix doesn't expose it — it calls python.nix without passing dependency-groups, so it always defaults to [ "all" ]:

hermesVenv = callPackage ./python.nix {
  inherit uv2nix pyproject-nix pyproject-build-systems;
  # dependency-groups is NOT passed — stuck at default ["all"]
};

if that understanding is flawed or there is a different way we're not thinking of, please correct me. If not, it might be that another issue/PR would be useful to allow dependency groups to be declared

Is this PR going to be merged? I'm having this exact issue with the Hermes agent on NixOS.

Hey @jbotwell, @descention, @mrhwick! Thanks for the patience on this one and for pushing on the issue. The discussion here (especially the comment about dependency-groups not being wired through) was really helpful in clarifying what the right fix actually looks like.

We've split this into two PRs that solve the problem without polluting [all]:

1. #21818 — feat(deps): add hindsight-client as optional dependency

Adds hindsight = ["hindsight-client>=0.4.22"] to pyproject.toml optional deps. Deliberately NOT in [all] — memory providers are plugins, and if we let hindsight in then supermemory, mem0, openviking all have equal claim and [all] becomes unbounded. This gives Docker/k8s users:

pip install hermes-agent[hindsight]

2. #21817 — feat(nix): add extraDependencyGroups for sealed venv extras

This addresses the gap @jbotwell identified — dependency-groups existed in python.nix but wasn't wired through hermes-agent.nix. Now it is. NixOS users can opt into any pyproject.toml extra inside the sealed venv (single uv resolver pass, no PYTHONPATH append, no collision checker):

services.hermes-agent.extraDependencyGroups = [ "hindsight" ];

This is cleaner than the extraPythonPackages workaround because uv resolves the full graph in one pass — no risk of transitive dep collisions with the sealed venv.

The two together give every environment a clean path:

• Nix: extraDependencyGroups = [ "hindsight" ]
• Docker/k8s: pip install hermes-agent[hindsight]
• Regular pip/uv: uv sync --extra hindsight

Would appreciate your eyes on both if you get a chance — especially @jbotwell since you traced the dependency-groups wiring gap that led to #21817.

Hey @jbotwell, @descention, @mrhwick! Thanks for the patience on this one and for pushing on the issue. The discussion here (especially the comment about dependency-groups not being wired through) was really helpful in clarifying what the right fix actually looks like.

We've split this into two PRs that solve the problem without polluting [all]:

1. #21818 — feat(deps): add hindsight-client as optional dependency

Adds hindsight = ["hindsight-client>=0.4.22"] to pyproject.toml optional deps. Deliberately NOT in [all] — memory providers are plugins, and if we let hindsight in then supermemory, mem0, openviking all have equal claim and [all] becomes unbounded. This gives Docker/k8s users:

pip install hermes-agent[hindsight]

2. #21817 — feat(nix): add extraDependencyGroups for sealed venv extras

This addresses the gap @jbotwell identified — dependency-groups existed in python.nix but wasn't wired through hermes-agent.nix. Now it is. NixOS users can opt into any pyproject.toml extra inside the sealed venv (single uv resolver pass, no PYTHONPATH append, no collision checker):

services.hermes-agent.extraDependencyGroups = [ "hindsight" ];

This is cleaner than the extraPythonPackages workaround because uv resolves the full graph in one pass — no risk of transitive dep collisions with the sealed venv.

The two together give every environment a clean path:

* **Nix**: `extraDependencyGroups = [ "hindsight" ]`

* **Docker/k8s**: `pip install hermes-agent[hindsight]`

* **Regular pip/uv**: `uv sync --extra hindsight`

Would appreciate your eyes on both if you get a chance — especially @jbotwell since you traced the dependency-groups wiring gap that led to #21817.

Yeah, took a look at those. No issues jumping out at me. I think the separation makes a lot more sense. Thanks!

Closed in favour of: #21818
Thank you @jbotwell @descention @mrhwick for the help!