Suriyakumarvijayanayagam
92573e9067
Ran behavision-setup in a fresh Linux container: Python 3.12, nothing else, the release contents mounted read-only the way Program Files or a shared drive would be. It failed, and then it failed differently, and both failures would have been the client's first experience. 1. `pip install <folder>` makes setuptools write behavision.egg-info INTO the folder. The folder is read-only wherever a release is sensibly unzipped, so: "could not create 'behavision.egg-info': Read-only file system". The release now ships a wheel - pure Python, buildable anywhere, nothing to build on the shop PC, and pip never touches the unzipped folder. Source stays as a fallback and is copied somewhere writable first. 2. The engine's paths.py knows two worlds - frozen (ProgramData) and a checkout (the repo root) - and a pip-installed engine is neither. It resolved its state root to site-packages: database there, camera list there, and its generated API credential in a folder the app never reads, while the app looked in ProgramData. Every call would be 401 on a stock install, with nothing in either log saying why. The same disease as the Mac checkout two days ago, now in production shape. engine.ChildEnv is the one place the engine's environment is built, used by the desktop app, the headless agent and the installer's own smoke test. It passes BEHAVISION_DATA_DIR = this process's state root, which paths.py honours ahead of every other rule, so the two halves agree by construction however the engine was installed. It also seeds config/default.yaml into the state root: a package in site-packages has no config beside it to seed from. Re-run on the same clean container: seven steps, all pass, models downloaded, engine started and answered, and its data/ landed beside agent.json - not in site-packages. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
Behavision agent (Go)
The half of the edge install that touches the network. The Python engine keeps the cameras and the models; this keeps the tray icon, the UI shell, the MQTT connection and the offline queue.
┌─ agent (Go) ───────────────────┐ ┌─ engine (Python) ────────┐
│ tray icon + WebView2 window │ │ RTSP capture │
│ supervises the engine process │───────▶│ YuNet / ArcFace / FAISS │
│ MQTT publish + offline spool │◀───────│ SQLite (biometric) │
│ S3 handoff, tenant config │ local │ localhost API + events │
└────────────────────────────────┘ HTTP └──────────────────────────┘
Why the split
Go cannot run ONNX, OpenCV or FAISS, so the engine stays Python and ships frozen. Go is here for what it is actually better at: a durable queue that survives a store's internet dropping, a supervised child process, and one language shared with the server so the MQTT contract has a single definition.
Why not a Windows service
A service runs in session 0 and cannot draw a tray icon — that is Windows session isolation, not a library limitation. Since the product is "user starts and stops it from the tray", the agent is a normal user-session process that spawns the engine as a child. That also means it never needs elevation at runtime: starting a child process does not, controlling a service does.
internal/engine is written so a service wrapper can be added later without
touching the supervision logic.
Layout
main.go entry point, mode dispatch
internal/engine start/stop/supervise the Python engine, health polling
internal/spool durable event queue (survives restart and outage)
internal/mqtt broker client, publishes from the spool
internal/config tenant identity, broker settings, credentials
frontend/ React UI served into the WebView
Build
go build ./... # agent alone
wails build # agent + frontend, once the UI is added