terp-cli 0.5.3__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.3 → terp_cli-0.5.4}/pyproject.toml

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

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

@@ -416,6 +416,26 @@ New projects start with it on, and the framework runs its own suites that way. S
 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)
@@ -754,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.3/PKG-INFO

@@ -1,16 +0,0 @@
-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'