fix(docker): keep the venv on PATH in login shells

[ugoenyioha]

Summary

Split out of #33179 as the focused docker-lane change @benbarclay asked for. One RUN line; the other two concerns from that PR are addressed separately (see the bottom).

ENV PATH puts /opt/hermes/bin and the venv ahead of the system paths, and ordinary processes inherit it. A login shell does not — it rebuilds PATH from /etc/profile and drops all of it.

Answering the question from #33179

Can you describe the path that hits this? … What's hitting bash -l inside the container? (Terminal-tool sessions? docker exec -it … bash -l? Something else?)

Terminal-tool sessions. tools/environments/docker.py::_run_bash() — docstring "Spawn a bash process inside the Docker container" — does:

cmd = [self._docker_exe, "exec"]
...
# Only inject -e env args during init_session (login=True).
if login:
    cmd.extend(self._init_env_args)
cmd.extend([self._container_id])
if login:
    cmd.extend(["bash", "-l", "-c", cmd_string])
else:
    cmd.extend(["bash", "-c", cmd_string])

init_session is the caller that passes login=True, so environment snapshotting runs under bash -l inside the container. Your read of main-wrapper.sh and the s6 run scripts was right — none of those are login shells. This is a different entry point.

Measured, not assumed

In a container built from this image, with no env overrides:

$ bash -c  'command -v python3; echo $PATH'
/opt/hermes/.venv/bin/python3
/opt/hermes/bin:/opt/hermes/.venv/bin:/opt/data/.local/bin:/usr/local/sbin:...

$ bash -lc 'command -v python3; echo $PATH'
/usr/bin/python3
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

The login shell loses the venv entirely and python3 falls back to the system interpreter, which has none of Hermes' dependencies. The failures that follow read as missing packages rather than as a PATH problem, which is what makes this slow to diagnose rather than merely broken.

One deviation from #33179

That PR's line prepended only /opt/hermes/.venv/bin:/opt/data/.local/bin, omitting /opt/hermes/bin. The ENV PATH comment right above explains why that comes first — it is the privilege-drop shim, and it must win resolution. Omitting it would leave login shells with the opposite precedence to every other process. This version mirrors the ENV ordering exactly.

Scope

• ENV S6_KEEP_ENV=1 from fix(docker): inject venv PATH into /etc/profile.d for login shells #33179 is dropped, as requested. It is a no-op now that fix(docker): propagate env through s6 to cont-init and main CMD #32412 has landed — I verified that separately and posted the measurement on fix(docker): set S6_KEEP_ENV=1 to preserve container environment #33148: on a current image the pod environment survives the s6 scrub without it.
• The Mattermost reply_mode = "auto" feature from fix(docker): inject venv PATH into /etc/profile.d for login shells #33179 is feat(mattermost): add 'auto' reply mode — flat DMs, threaded channels #33149, reworked against the current centralized resolver.

[alt-glitch]

This was generated by AI during triage.

Related to #64849 and #56642: all address the Debian login-shell PATH reset. This PR is the focused image-layer variant; #64849 adds broader Docker environment-forwarding coverage, while #56642 repairs the local shell runner.

[ugoenyioha]

Closing as a duplicate — #64849 predates this and is strictly more complete: a versioned docker/profile.d/99-hermes-venv-path.sh with an idempotency guard, plus the snapshot layer in tools/environments/{base,docker,local}.py that this PR ignores, plus tests. #56642 covers the terminal-snapshot half of the same root cause.

I should have run the duplicate search in CONTRIBUTING's "Before You Start" section before writing this. I've moved the useful part — a before/after PATH measurement from a pristine container, and the caller that puts this on the normal terminal-tool path (tools/environments/docker.py::_run_bash() with login=True, via init_session) — to #64849 as review evidence.

No action needed here; #64849 is the one to land.