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

terp_cli-0.5.4/PKG-INFO

@@ -0,0 +1,16 @@
+Metadata-Version: 2.4
+Name: terp-cli
+Version: 0.5.4
+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.4
+Requires-Dist: terp-core==0.5.4
+Requires-Dist: terp-migrations==0.5.4
+Provides-Extra: jobs
+Requires-Dist: terp-cap-outbox==0.5.4; extra == 'jobs'
+Requires-Dist: terp-cap-scheduler-apscheduler==0.5.4; extra == 'jobs'
+Provides-Extra: scheduler
+Requires-Dist: terp-cap-scheduler-apscheduler==0.5.4; extra == 'scheduler'
+Provides-Extra: worker
+Requires-Dist: terp-cap-outbox==0.5.4; extra == 'worker'

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

@@ -4,29 +4,29 @@ build-backend = "hatchling.build"
 
 [project]
 name = "terp-cli"
-version = "0.5.2"
+version = "0.5.4"
 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.4",
     # `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.4",
     # `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.4",
 ]
 
 # 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.4"]
+scheduler = ["terp-cap-scheduler-apscheduler==0.5.4"]
 jobs = [
-    "terp-cap-outbox==0.5.2",
-    "terp-cap-scheduler-apscheduler==0.5.2",
+    "terp-cap-outbox==0.5.4",
+    "terp-cap-scheduler-apscheduler==0.5.4",
 ]
 
 [project.scripts]

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

@@ -372,25 +372,70 @@ 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.
+
+AND READ THE GREEN HONESTLY. Strict mode resets BEFORE fixtures run, so it can only see
+installs that happen before the suite. An autouse fixture that installs a runtime for a
+whole package is invisible to it - every test gets a bus it never asked for, and strict
+mode agrees with you every time. So: a green strict run does NOT mean your installs are
+precise, only that none of them happen before the suite. Ask the other half instead:
+      uv run pytest --terp-report-runtime-installs
+which reports, per seam, the tests that installed it. Read the SHAPE of the answer: one or
+two ids under a seam is a test installing what it needs; every id in a package under one
+seam is a fixture installing it for them. Then make that installer NAMED and non-autouse,
+and let the tests that emit request it. The ones that then fail were the ones being carried.
+
+TWO FIXTURES, ONE SEAM. A seam holds one runtime, so the last install wins - and pytest
+decides "last" from the FIXTURE GRAPH, not from the order of your test's parameters. A tap
+that installs a recording dispatcher after the catalog fixture must DEPEND on it:
+      @pytest.fixture
+      def emitted(events_runtime: None, terp_events: InstallEvents) -> list[object]:
+          ...
+Getting it the wrong way round is silent: the tap installs first, the catalog fixture
+overwrites it, and the recorder simply records nothing.
 """,
     "jobs": """\
 Background jobs (terp.core.enqueue + JobCatalog)
@@ -729,14 +774,26 @@ Data collections (DataView)
   refused by the boundary lint. It gives search, sorting, pagination, column management,
   selection + batch actions, row actions, expandable rows, and persisted view
   preferences, driven by a repository port.
-- Client-side (small collections — rows already in memory):
-      const repo = useMemo(() => new InMemoryDataViewRepository(rows), [rows]);
-      <DataView repository={repo} columns={columns} keyField="id" />
+- Client-side (small collections — rows already in memory). The repository owns row
+  identity and value access; the component never reads a field itself:
+      const repo = useMemo(
+        () =>
+          new InMemoryDataViewRepository(rows, {
+            getRowId: (r) => r.id,
+            getValue: (r, col) => r[col as keyof Row],
+            searchFields: ["title", "status"],
+          }),
+        [rows],
+      );
+      <DataView repository={repo} columns={columns} viewId="notes.list" />
 - Server-side (large collections — let the backend paginate/sort/filter):
       const repo = useMemo(() => new HttpDataViewRepository({...}), [client]);
   and keep query state in the URL with useServerDataView.
-- Columns declare {key, header, render?}; header text is UiText. Row actions and batch
-  actions are declared as data (the component renders the token-styled controls).
+- Columns declare {id, header, accessor?, cell?, enableSorting?, meta?} — `id` is the
+  column key the repository's getValue receives, `accessor` reads the value and `cell`
+  renders it; header text is UiText. There is no `keyField` prop: row identity is
+  `getRowId` on the repository. Row actions and batch actions are declared as data
+  (the component renders the token-styled controls).
 - Persist per-user view preferences via the ViewStateRepository seam
   (LocalStorageViewStateRepository for the browser; InMemoryViewStateRepository in tests).
 - For a simple titled CRUD list (no tables), ResourceList over useResource is the

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'