Skip to content
Apothem
Architektur

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)
  • jsonschema mit seiner Abhängigkeitskette attrs (und dessen Alias attr), referencing und jsonschema_specifications
  • rpds — ein reiner Python-Shim, der die von jsonschema und referencing verwendete Oberfläche aus HashTrieMap, HashTrieSet und List auf Basis eingebauter Typen neu implementiert, sodass der Stack ohne jede kompilierte Erweiterung läuft
  • typing_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ächeAufrufKontext
Engine-CLIpython -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 apothem führt src/apothem/__main__.py aus, das src/apothem/_vendor in den sys.path aufnimmt, prüft, dass click und rich importierbar sind, und dann apothem.cli:main aufruft — die Click-Befehlsgruppe.
  • Hook-Einträge in der materialisierten settings.json / hooks.json rufen 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 eigenen sys.path bootstrappen, und die Schema-Fixtures des Gates liegen neben ihm unter <harness-root>/.apothem/support/schemas/, sodass Hooks ohne importierbares apothem-Paket auf dem Host laufen. Die Templates tragen ein ${HARNESS_ROOT}-Token, das apothem install zum tatsächlichen Harness-Wurzelpfad in Schreibweise mit Vorwärtsschrägstrichen rendert.
  • Aus einem Quell-Checkout führen die Modulformen python -m apothem.hooks.dispatch und python -m apothem.conformity.gate denselben 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.

On this page