Eigenständige Laufzeit
Wie Apothems Engine aus jedem Checkout läuft — gevendorte Abhängigkeiten, das Aufrufmodell PYTHONPATH=src und der Bootstrap des Plugin-Baums.
Eigenständige Laufzeit
Apothems Engine ist eine eigenständige Laufzeit: Sie läuft ohne Registry,
direkt aus jedem Checkout oder abgelegten Quellbaum, weil ihre
Drittanbieter-Abhängigkeiten mit ihr reisen. Zwei Bausteine machen das möglich —
ein gevendorter Abhängigkeitsbaum und ein python -m-Aufrufmodell, das keine
installierten Konsolenskripte benötigt.
Gevendorter Abhängigkeitsbaum
Der Validierungs- und Serialisierungs-Stack ist als reiner Python-Quellcode
unter src/apothem/_vendor/ gevendort, jedes Paket neben seiner
Upstream-Lizenzdatei:
yaml(der reine Python-Parser/-Emitter; die optionale C-Erweiterung libyaml wird nicht mitgeführt)jsonschemamit seiner Abhängigkeitsketteattrs(und dessen Aliasattr),referencingundjsonschema_specificationsrpds— ein reiner Python-Shim, der die vonjsonschemaundreferencingverwendete Oberfläche ausHashTrieMap,HashTrieSetundListauf Basis eingebauter Typen neu implementiert, sodass der Stack ohne jede kompilierte Erweiterung läufttyping_extensions
Gevendorte Kopien haben Vorrang vor jeder systemweit installierten Version: Der
Plugin-Bootstrap, der npm-Shim, die Installer und der Einstiegspunkt
python -m apothem selbst stellen das Vendor-Verzeichnis jeweils vor
site-packages in den sys.path. Die Auswahlrichtlinie — was gevendort wird, was
nicht und wie gevendorte Pakete aufgefrischt werden — ist in der
Strategie für das Vendoring von Abhängigkeiten
dokumentiert.
Zwei Abhängigkeiten bleiben außerhalb des Baums: click und rich, die
terminalseitigen Bibliotheken, die die CLI importiert. Sie müssen unter dem
Interpreter importierbar sein, der die Engine ausführt; die Installer prüfen
beide, nennen jede fehlende und bieten an, sie für Sie zu installieren — mit
Ihrer Bestätigung oder automatisch mit --yes / APOTHEM_AUTO_INSTALL_DEPS=1.
Auf jedem anderen Kanal prüft der Einstiegspunkt beide mit der
Standardbibliothek, bevor er die CLI importiert, und eine fehlende stoppt ihn
mit einem Fehler, der den exakten pip-Befehl für den laufenden Interpreter
nennt (unter --json ein JSON-Umschlag mit dem Code
runtime.dependency_missing).
Das python -m-Aufrufmodell
Apothem deklariert absichtlich keine Konsolenskripte in pyproject.toml —
Konsolenskripte existieren nur, wenn ein Paketmanager sie auf den PATH legt,
und die eigenständige Laufzeit setzt niemals einen voraus. Die Engine hat
stattdessen zwei Aufrufoberflächen:
| Oberfläche | Aufruf | Kontext |
|---|---|---|
| Engine-CLI | python -m apothem <command> | Ein Quellbaum mit src/ auf dem PYTHONPATH (Checkout, npx-Cache, Plugin-Baum) |
| Hook-Laufzeit | <resolved CPython> "<harness-root>/.apothem/support/hooks/dispatch.py" <event> | Die Materialisierung für Claude Code: die Kopie im gemeinsamen Baum .apothem/support/ der Harness-Wurzel, per absolutem Pfad |
python -m apothemführtsrc/apothem/__main__.pyaus, dassrc/apothem/_vendorin densys.pathaufnimmt, prüft, dassclickundrichimportierbar sind, und dannapothem.cli:mainaufruft — die Click-Befehlsgruppe.- Hook-Einträge in der materialisierten
settings.json/hooks.jsonrufen den Dispatcher (und, für Claude Code, das Konformitäts-Gate unter<harness-root>/.apothem/support/conformity/gate.py) per absolutem Skriptpfad auf. Beide sind eigenständige stdlib-Skripte, die ihren eigenensys.pathbootstrappen, und die Schema-Fixtures des Gates liegen neben ihm unter<harness-root>/.apothem/support/schemas/, sodass Hooks ohne importierbaresapothem-Paket auf dem Host laufen. Die Templates tragen ein${HARNESS_ROOT}-Token, dasapothem installzum tatsächlichen Harness-Wurzelpfad in Schreibweise mit Vorwärtsschrägstrichen rendert. - Aus einem Quell-Checkout führen die Modulformen
python -m apothem.hooks.dispatchundpython -m apothem.conformity.gatedenselben Code für die Entwicklung aus.
Das Paketverzeichnis wird importierbar, indem das src/-Verzeichnis des
Checkouts dem PYTHONPATH vorangestellt wird:
PYTHONPATH="$HOME/.apothem/src" python -m apothem <command>Wenn der Starter apothem nicht im PATH liegt, gibt install.sh bei Abschluss
diese Form aus, mit dem vendored-Verzeichnis vor src/ und dem CPython, den es
aufgelöst hat, an Stelle von python. install.ps1 gibt dieselben zwei
Einstellungen in PowerShell-Form aus: eine Zuweisung an $env:PYTHONPATH, die
das vendored-Verzeichnis und das Verzeichnis src/ mit ; verbindet, danach
& '<CPython>' -m apothem <command>.
Bootstrap des Plugin-Baums
Das Claude Code-Plugin bündelt die Engine unter <plugin_root>/lib/apothem,
statt sich auf PYTHONPATH zu verlassen. Das Bootstrap-Modul
apothem.lib.plugin_bootstrap stellt bootstrap_syspath bereit, das
idempotent <plugin_root>/lib und das Vendor-Verzeichnis dem sys.path
voranstellt, sodass import apothem und jede gevendorte Abhängigkeit aus dem
Plugin-Baum aufgelöst werden. Ein fehlerhafter Baum (fehlendes lib/) löst
PluginBootstrapError aus, statt stillschweigend eine veraltete Systemkopie zu
importieren.
Was der Installer auf dem Datenträger ablegt
Die Skript-Installer legen einen git-Klon des Quellbaums unter ~/.apothem ab
(überschreibbar mit APOTHEM_HOME) und führen die Engine daraus aus — über das
optionale Angebot der Voraussetzungen click / rich hinaus werden keine
Python-Pakete in site-packages installiert. Der Klon ist das vollständige
Repository, einschließlich der Testsuite und der Dokumentationsseite, die die
Laufzeit niemals importiert, und zwar aus zwei bewussten Gründen: Die Engine
materialisiert ihre Kohorten — Regeln, Skills, Befehle und Templates —
direkt aus dem Baum in jeden Harness, sodass der Baum die lebendige Quelle der
Wahrheit ist und nicht nur eine Laufzeit; und das .git-Verzeichnis bleibt an
Ort und Stelle, sodass apothem update den Release-Tag im bestehenden Klon
auscheckt, statt neu herunterzuladen.
Dieses Layout der Ausführung aus dem Quellcode ist dasselbe Muster, das
Werkzeuge wie nvm, pyenv und oh-my-zsh verwenden — wenige Megabyte
Quellcode plus Verlauf, in einem Schritt mit dem Deinstallationsprogramm
entfernbar (es gibt keinen Systemzustand, der rückgängig zu machen wäre). Ein
schlankerer Fußabdruck — ein flacher oder spärlicher Checkout, der tests/ und
site/ weglässt — ist möglich, würde aber den direkt vor Ort ausgeführten,
signaturgeprüften, git-basierten Aktualisierungspfad preisgeben; das aktuelle
Layout bevorzugt eine einfache, verifizierbare Aktualisierung gegenüber
minimalem Speicherbedarf.
Wie die Laufzeit Python findet
Die Ein-Schritt-Installer und der npx-Shim sondieren unterschiedliche Namen und
wenden dieselben Regeln an. Die Installer sondieren python3, python und die
versionierten Namen (python3.14 bis python3.10). Der npx-Shim sondiert
APOTHEM_PYTHON, wenn die Variable gesetzt ist, danach python3, python und
py -3; er hat keine versionierten Namen. Beide weisen Launcher-Shims des
Microsoft Store zurück und akzeptieren den ersten Kandidaten, der Version 3.10
oder neuer meldet. Bei Ausführung aus einem Quellbaum verwenden die Installer
den gebündelten Locator hooks/lib/find-python wieder, der dieselbe Untergrenze
anwendet.
Empfohlener nächster Schritt
Führen Sie python -m apothem --help aus, mit dem src/-Verzeichnis des
Checkouts auf dem PYTHONPATH, um zu bestätigen, dass der Pfad der
eigenständigen CLI auf Ihrem Host aufgelöst wird.
Installations-Workflow
Wie apothem install, update und uninstall durchgängig funktionieren.
Strategie zur Abhängigkeits-Internalisierung
Welche Drittanbieter-Pakete Apothem unter src/apothem/_vendor/ internalisiert, welche Systemvoraussetzungen bleiben und wie internalisierte Kopien aktualisiert werden.