bug(gateway): systemd service unit hardcodes venv/ path, breaks when virtualenv is .venv

[joeynyc]

Description

generate_systemd_unit() and get_python_path() in hermes_cli/gateway.py hardcode venv as the virtualenv directory name. When the virtualenv is created as .venv (which setup-hermes.sh and .gitignore both reference), the generated systemd unit has incorrect VIRTUAL_ENV and PATH environment variables pointing to a nonexistent venv/ directory.

Impact

• ExecStart works correctly because get_python_path() falls back to sys.executable when venv/bin/python doesn't exist
• But VIRTUAL_ENV and PATH in the unit file point to PROJECT_ROOT/venv/ which doesn't exist
• This can cause subprocesses, tools, or pip invocations within the gateway to resolve incorrectly

Steps to Reproduce

1. Install hermes-agent with .venv as the virtualenv directory name
2. Run hermes gateway install
3. Inspect the generated unit file at ~/.config/systemd/user/hermes-gateway.service
4. Observe VIRTUAL_ENV and PATH reference venv/ instead of .venv/

Suggested Fix

In hermes_cli/gateway.py:

• get_python_path() (lines 376-378): check for both .venv and venv
• generate_systemd_unit() (lines 402-403): detect the actual virtualenv directory instead of hardcoding venv
• Simplest approach: use sys.prefix to get the active virtualenv path at install time

Environment

• OS: Ubuntu 22.04 on WSL2
• Python: 3.11.13
• Hermes Agent: v0.4.0

[joeynyc]

OK awesome. I will close this issue then. Good work.

[teknium1]

Reopening — the bug is still present on main. get_python_path() and generate_systemd_unit() both still hardcode venv/. Three open PRs address this (#2493, #2500, #2518).

[teknium1]

Fixed in PR #2797 (salvaged from #2493 by @Mibayy). _detect_venv_dir() now checks sys.prefix first, then probes .venv and venv under the project root. Both get_python_path() and generate_systemd_unit() use it.