`gj |dZddlmZddlZddlZej dk(Zdad dZd d dZ d dZ ee y) uWindows UTF-8 bootstrap for Hermes entry points. Python on Windows has two long-standing text-encoding footguns: 1. ``sys.stdout`` / ``sys.stderr`` are bound to the console code page (``cp1252`` on US-locale installs), so ``print("café")`` crashes with ``UnicodeEncodeError: 'charmap' codec can't encode character``. 2. Child processes spawned via ``subprocess`` don't know to use UTF-8 unless ``PYTHONUTF8`` and/or ``PYTHONIOENCODING`` are set in their environment — so any Python subprocess (the execute_code sandbox, delegation children, linter subprocesses, etc.) inherits the same cp1252 defaults and hits the same UnicodeEncodeError. This module fixes both on Windows *only* — POSIX is untouched. It should be imported at the very top of every Hermes entry point (``hermes``, ``hermes-agent``, ``hermes-acp``, ``python -m gateway.run``, ``batch_runner.py``, ``cron/scheduler.py``) before any other imports that might do file I/O or print to stdout. What this module does on Windows: - Sets ``os.environ["PYTHONUTF8"] = "1"`` (PEP 540 UTF-8 mode) so every child process we spawn uses UTF-8 for ``open()`` and stdio. - Sets ``os.environ["PYTHONIOENCODING"] = "utf-8"`` for belt-and- suspenders — some tools read this instead of / in addition to ``PYTHONUTF8``. - Reconfigures ``sys.stdout`` / ``sys.stderr`` to UTF-8 in the current process, using the ``reconfigure()`` API (Python 3.7+). This fixes ``print("café")`` in the parent without a re-exec. What this module does NOT do: - It does not re-exec Python with ``-X utf8``, so ``open()`` calls in the *current* process still default to locale encoding. Those need an explicit ``encoding="utf-8"`` at the call site (lint rule ``PLW1514`` / ``PYI058``). Ruff is the right tool for that sweep. What this module does on POSIX: - Nothing. POSIX systems are already UTF-8 by default in 99% of cases, and we don't want to touch ``LANG``/``LC_*`` behavior that users may have configured intentionally. If someone hits a C/POSIX locale on Linux, they can export ``PYTHONUTF8=1`` themselves — we won't override. Idempotent: safe to call multiple times. ``_bootstrap_once`` guards against double-reconfigure. ) annotationsNwin32Fctsytrytjj ddtjj dddD]1}t t |d}|t |dd}|' |dd 3t t d d}|t |dd}| |dd d ay d ay #ttf$rYxwxYw#ttf$rYd ay wxYw) ulApply the Windows UTF-8 bootstrap if we're on Windows. Returns True if bootstrap was applied (i.e. we're on Windows and haven't already done this), False otherwise. The return value is advisory — callers normally don't need it, but tests may want to assert the path was taken. Idempotent: subsequent calls after the first are a no-op. F PYTHONUTF81PYTHONIOENCODINGzutf-8)stdoutstderrN reconfigurereplace)encodingerrorsstdinT) _IS_WINDOWS_bootstrap_appliedosenviron setdefaultgetattrsysOSError ValueError) stream_namestreamr rs C/root/.hermes/venv/lib/python3.12/site-packages/hermes_bootstrap.pyapply_windows_utf8_bootstrapr;s  JJ,,JJ,g6, k40 > fmT:      ;( C$ 'E e]D9  " WY?  #$   Z(    s$9 B8( C 8C  C  C! C!cl|xsatjjdxs@tjj tjj t }tjDcgc] }|dvs| c}tjddtjj |}tjDcgc]'}tjj ||k7s&|)c}tjddtjjd|ycc}wcc}w)uStop a package in the current directory from shadowing Hermes modules. Hermes ships top-level modules with common names (``utils``, ``proxy``, ``ui``). Python always seeds ``sys.path`` with the current directory, so launching an entry point from a project that has its own ``utils/`` package makes ``from utils import ...`` resolve to the *user's* package and crash with an ImportError before the gateway can even start. The current directory reaches ``sys.path`` two ways, and a complete guard has to handle both: - As the empty string ``""`` (or ``"."``) that Python inserts at ``sys.path[0]`` for ``-m`` / script launches. - As its own *absolute* path, when a venv activation or a project that adds itself to ``PYTHONPATH`` puts the directory there explicitly. We drop the relative forms outright, then force the real Hermes source root to the front — relocating it ahead of any absolute cwd entry rather than only inserting when absent, so an absolute cwd path can't keep winning. ``src_root`` defaults to the directory this module lives in, which is the repository root for every shipped entry point, so the guard is self-sufficient and does not depend on the spawner exporting an env var. HERMES_PYTHON_SRC_ROOT).Nr) rrgetpathdirnameabspath__file__rinsert)src_rootrootproot_abss rharden_import_pathr+}s2  rzz~~&>? 277?? !DD"hh=!9*<1=CHHQKwwt$H!hhI"''//!*<*H1ICHHQKHHOOAt >Js8 D,D, 'D13D1ctjjddjsy ddlm}|j y#t$rYywxYw)uPut the durable lazy-install dir on ``sys.path`` if one is configured. On immutable Docker images the agent venv is sealed and lazy installs are redirected to a writable dir on the data volume (``HERMES_LAZY_INSTALL_TARGET``, e.g. ``/opt/data/lazy-packages``). Packages installed there on a previous run must be importable on this run, so we activate the dir here — at the very first import, before any backend module imports its SDK. The activation appends to the END of ``sys.path`` so the core venv always wins name collisions (see ``tools.lazy_deps`` for the full security rationale). Never raises; a missing/empty target is a no-op. HERMES_LAZY_INSTALL_TARGETrNr lazy_deps)rrr!striptoolsr/activate_durable_lazy_target Exceptionr.s rr2r2sK ::>>6 ; A A C #..0    sA AA)returnbool)N)r'z str | Noner4None)r4r6) __doc__ __future__rrrplatformrrrr+r2rr<sK/b# llg% ?D!H : r;