terp-cli 0.5.2__tar.gz → 0.5.3__tar.gz

terp_cli-0.5.3/PKG-INFO

@@ -0,0 +1,16 @@
+Metadata-Version: 2.4
+Name: terp-cli
+Version: 0.5.3
+Summary: Terp command-line tool — inspect, scaffolding, migrations, checks, api-docs.
+License-Expression: Apache-2.0
+Requires-Python: >=3.13
+Requires-Dist: terp-arch==0.5.3
+Requires-Dist: terp-core==0.5.3
+Requires-Dist: terp-migrations==0.5.3
+Provides-Extra: jobs
+Requires-Dist: terp-cap-outbox==0.5.3; extra == 'jobs'
+Requires-Dist: terp-cap-scheduler-apscheduler==0.5.3; extra == 'jobs'
+Provides-Extra: scheduler
+Requires-Dist: terp-cap-scheduler-apscheduler==0.5.3; extra == 'scheduler'
+Provides-Extra: worker
+Requires-Dist: terp-cap-outbox==0.5.3; extra == 'worker'

{terp_cli-0.5.2 → terp_cli-0.5.3}/pyproject.toml

@@ -4,29 +4,29 @@ build-backend = "hatchling.build"
 
 [project]
 name = "terp-cli"
-version = "0.5.2"
+version = "0.5.3"
 description = "Terp command-line tool — inspect, scaffolding, migrations, checks, api-docs."
 requires-python = ">=3.13"
 license = "Apache-2.0"
 dependencies = [
-    "terp-core==0.5.2",
+    "terp-core==0.5.3",
     # `terp migrate` delegates to terp-migrations (lazily imported), keeping Alembic
     # off the path for `terp inspect` / `terp guide` while making migrations work.
-    "terp-migrations==0.5.2",
+    "terp-migrations==0.5.3",
     # `terp guide rules` projects the live rule registry; terp-arch is imported lazily
     # (only when that topic is rendered), so it stays off the common `terp guide` path.
-    "terp-arch==0.5.2",
+    "terp-arch==0.5.3",
 ]
 
 # Job-process adapters stay optional: the base CLI must not install the table-owning outbox
 # or a scheduler engine into apps that only use inspect/check/migrate. Deployments can select
 # one process role, while `jobs` is the convenient complete jobs-process bundle.
 [project.optional-dependencies]
-worker = ["terp-cap-outbox==0.5.2"]
-scheduler = ["terp-cap-scheduler-apscheduler==0.5.2"]
+worker = ["terp-cap-outbox==0.5.3"]
+scheduler = ["terp-cap-scheduler-apscheduler==0.5.3"]
 jobs = [
-    "terp-cap-outbox==0.5.2",
-    "terp-cap-scheduler-apscheduler==0.5.2",
+    "terp-cap-outbox==0.5.3",
+    "terp-cap-scheduler-apscheduler==0.5.3",
 ]
 
 [project.scripts]

{terp_cli-0.5.2 → terp_cli-0.5.3}/src/terp/cli/__init__.py

@@ -372,25 +372,50 @@ Domain events (eventbus capability)
     "testing": """\
 Testing a Terp app (process-global runtime isolation)
 
-- create_app installs SIX process globals per app: the audit policy+sink, the event
-  catalog+dispatcher, the job catalog+queue, the schedule catalog, the password policy,
-  and the decrypt call site. In a test process they outlive the app that installed them.
-- You get isolation for free. terp-core ships a pytest plugin (terp.core.testing,
-  registered under pytest11) whose autouse fixture SNAPSHOTS every runtime before a
-  test and RESTORES it after. No conftest.py line, no opt-in. Without it a suite goes
-  order-dependent: green together, red alone - the sharpest failure mode there is,
-  because the green is the wrong answer.
-- Isolation does not INSTALL a runtime your test needs - that is your decision:
+WHAT YOU MUST STILL DO YOURSELF. The platform UNDOES a runtime; it never INSTALLS the
+one your test needs. That distinction is the whole of testing on Terp:
       * whole runtime -> compose the app in a fixture (see apps/example/tests/conftest.py,
         where db_engine + app_db are function-scoped and build() runs per test)
       * only the event bus -> the `terp_events` fixture, which installs a catalog
         (and dispatcher) for the duration of one test:
             terp_events(event_catalog, dispatcher=dispatch_in_process)
+        Annotate it `InstallEvents` (exported from terp.core.testing) - it carries
+        configure_events' real signature, so a wrong catalog is a type error.
       * asserting on what was written to a FAKE/bare session -> `terp_default_runtime`,
         which states the baseline instead of assuming it. Without it a composed app's
         durable audit sink quietly adds audit rows to the session under assertion.
-- If a test passes in the suite and fails alone (or vice versa), it is reading a
-  runtime it never installed. Install it explicitly; never re-order the suite.
+Deleting a conftest that INSTALLS something is not part of adopting the plugin.
+
+WHAT YOU GET FOR FREE. terp-core ships a pytest plugin (terp.core.testing, registered
+under pytest11) whose autouse fixture SNAPSHOTS every runtime before a test and
+RESTORES it after. No conftest.py line, no opt-in. Without it a suite goes
+order-dependent: green together, red alone - the sharpest failure mode there is,
+because the green is the wrong answer.
+
+THE SIX SEAMS. create_app installs six process globals per app; in a test process they
+outlive the app that installed them. Restored automatically -- but installed by you:
+
+      seam         what create_app installs        who installs it in a test
+      audit        audit policy + durable sink     compose the app, else the log-only
+                                                   default (terp_default_runtime)
+      events       event catalog + dispatcher      compose the app, or `terp_events`
+      jobs         job catalog + queue             compose the app
+      scheduling   schedule catalog                compose the app
+      passwords    password policy                 compose the app, else the default
+      secrets      the decrypt call site           compose the app (a secrets capability)
+
+STRICT MODE. Restoring is faithful, which is also its blind spot: a runtime installed
+BEFORE the first test (a stray `import app.main` at collection time, a module-scope
+create_app()) is part of the snapshot, so it is restored before every test and covers
+every test equally - green together, red alone, with nothing having leaked. Strict mode
+follows the snapshot with a RESET, so every test starts from the platform baseline and
+a test that only ever passed on ambient state fails where it stands:
+      [tool.pytest.ini_options]
+      terp_strict_isolation = true          # or: pytest --terp-strict-isolation
+New projects start with it on, and the framework runs its own suites that way. Switching
+it on in an existing suite can turn a green red - that red is the finding, not the
+regression: the test was reading a runtime it never installed. Install it explicitly;
+never re-order the suite.
 """,
     "jobs": """\
 Background jobs (terp.core.enqueue + JobCatalog)

terp_cli-0.5.2/PKG-INFO

@@ -1,16 +0,0 @@
-Metadata-Version: 2.4
-Name: terp-cli
-Version: 0.5.2
-Summary: Terp command-line tool — inspect, scaffolding, migrations, checks, api-docs.
-License-Expression: Apache-2.0
-Requires-Python: >=3.13
-Requires-Dist: terp-arch==0.5.2
-Requires-Dist: terp-core==0.5.2
-Requires-Dist: terp-migrations==0.5.2
-Provides-Extra: jobs
-Requires-Dist: terp-cap-outbox==0.5.2; extra == 'jobs'
-Requires-Dist: terp-cap-scheduler-apscheduler==0.5.2; extra == 'jobs'
-Provides-Extra: scheduler
-Requires-Dist: terp-cap-scheduler-apscheduler==0.5.2; extra == 'scheduler'
-Provides-Extra: worker
-Requires-Dist: terp-cap-outbox==0.5.2; extra == 'worker'