cassis-cli 3.1.0__tar.gz → 3.1.1__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/PKG-INFO +2 -2
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/README.md +1 -1
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/ontology.py +7 -1
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/status.py +15 -2
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/pyproject.toml +1 -1
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/LICENSE +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/NOTICE +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/__init__.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/api.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/common.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/eval.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/guide.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/issues.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/main.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/ontology_design_guide.md +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/projects.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/schema.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/schema_plan.py +0 -0
- {cassis_cli-3.1.0 → cassis_cli-3.1.1}/cassis_cli/verify.py +0 -0
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.4
|
|
2
2
|
Name: cassis-cli
|
|
3
|
-
Version: 3.1.
|
|
3
|
+
Version: 3.1.1
|
|
4
4
|
Summary: Validate, test and evaluate your Cassis context from your terminal, then publish it
|
|
5
5
|
License: Apache-2.0
|
|
6
6
|
License-File: LICENSE
|
|
@@ -27,7 +27,7 @@ Validate, test and evaluate your context from your terminal, then publish it. Th
|
|
|
27
27
|
- `cassis context check` validates the context files in your repository with the exact same checks as the Cassis GitHub PR check (YAML parsing, round-trip, import validation), so you can gate merges in any CI system, not just GitHub. It then prints advisory **context quality warnings** for a tree that parsed: tables not assigned to any domain, joins/metrics pointing at unknown tables or columns, missing table/column descriptions (the same findings `context test` reports, without the agent run). In a checkout bound to a project (`project.yml`, `--project`, or `CASSIS_PROJECT_ID`), it also cross-checks the tree against the project's source schema: references to tables or columns the warehouse doesn't have print as **warnings** too, advisory only (the object may simply not be built or synced yet). Warnings never fail the check.
|
|
28
28
|
- `cassis schema pull` downloads the data source's full source schema (as Cassis last introspected it) into `<base-path>/.schema.json`, a **gitignored** local snapshot (the command maintains the ignore entry) with a `pulled_at` stamp. The warehouse stays authoritative; the snapshot is a cache for offline/bulk work, e.g. a coding agent grepping table and column names during a modeling pass instead of paging through the MCP `get_source_schema` tool. Re-run to refresh.
|
|
29
29
|
- `cassis context fmt` rewrites the context files in canonical form (think `black`/`gofmt` for your context), so hand or agent edits pass the round-trip check.
|
|
30
|
-
- `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, so `cassis status` can tell whether a checkout matches what is live.
|
|
30
|
+
- `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, even when the upload changes nothing, so `cassis status` can tell whether a checkout matches what is live.
|
|
31
31
|
- `cassis context pull` downloads the project's unpublished context into your repository checkout (full sync: stale local context files are pruned), so you can start editing from the current state, or bootstrap a repo that isn't git-synced (e.g. Bitbucket). Pruning only deletes files that are tracked and unmodified in git (i.e. restorable with `git checkout`); untracked or locally modified files are kept and listed, and every deleted path is printed.
|
|
32
32
|
- `cassis context pull` and `cassis context fmt` also write `<base-path>/AGENTS.md`, the Cassis context design guide, into the checkout (default `cassis/AGENTS.md`). It is a managed file (generated banner; the CLI overwrites local edits) so a repo-aware coding agent loads current Cassis modeling doctrine by convention. It sits inside the context directory but is not part of the context tree (which is the YAML files plus the domain Markdown files `domains/**/README.md`), so it is never uploaded, validated, or pruned. Commit it alongside your context changes. The guide text ships inside the CLI package, so its version tracks the **installed cassis-cli version**: upgrade the CLI (`pip install -U cassis-cli`) and re-run `fmt` to pick up doctrine updates; an unpinned `pip install cassis-cli` in CI gets them automatically. The banner stamps a doctrine version, and the CLI never *downgrades* the file: if the checkout's `AGENTS.md` was written by a newer doctrine (a newer CLI, or Cassis itself on a publish), `fmt`/`pull` leave it in place, print an upgrade notice, and `fmt --check` still passes.
|
|
33
33
|
- The CLI identifies itself to the API (`User-Agent: cassis-cli/<version>`), and successful API responses advertise the newest published version. When you are behind, commands print a one-line upgrade notice on stderr (purely informational; output and exit codes are unchanged).
|
|
@@ -5,7 +5,7 @@ Validate, test and evaluate your context from your terminal, then publish it. Th
|
|
|
5
5
|
- `cassis context check` validates the context files in your repository with the exact same checks as the Cassis GitHub PR check (YAML parsing, round-trip, import validation), so you can gate merges in any CI system, not just GitHub. It then prints advisory **context quality warnings** for a tree that parsed: tables not assigned to any domain, joins/metrics pointing at unknown tables or columns, missing table/column descriptions (the same findings `context test` reports, without the agent run). In a checkout bound to a project (`project.yml`, `--project`, or `CASSIS_PROJECT_ID`), it also cross-checks the tree against the project's source schema: references to tables or columns the warehouse doesn't have print as **warnings** too, advisory only (the object may simply not be built or synced yet). Warnings never fail the check.
|
|
6
6
|
- `cassis schema pull` downloads the data source's full source schema (as Cassis last introspected it) into `<base-path>/.schema.json`, a **gitignored** local snapshot (the command maintains the ignore entry) with a `pulled_at` stamp. The warehouse stays authoritative; the snapshot is a cache for offline/bulk work, e.g. a coding agent grepping table and column names during a modeling pass instead of paging through the MCP `get_source_schema` tool. Re-run to refresh.
|
|
7
7
|
- `cassis context fmt` rewrites the context files in canonical form (think `black`/`gofmt` for your context), so hand or agent edits pass the round-trip check.
|
|
8
|
-
- `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, so `cassis status` can tell whether a checkout matches what is live.
|
|
8
|
+
- `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, even when the upload changes nothing, so `cassis status` can tell whether a checkout matches what is live.
|
|
9
9
|
- `cassis context pull` downloads the project's unpublished context into your repository checkout (full sync: stale local context files are pruned), so you can start editing from the current state, or bootstrap a repo that isn't git-synced (e.g. Bitbucket). Pruning only deletes files that are tracked and unmodified in git (i.e. restorable with `git checkout`); untracked or locally modified files are kept and listed, and every deleted path is printed.
|
|
10
10
|
- `cassis context pull` and `cassis context fmt` also write `<base-path>/AGENTS.md`, the Cassis context design guide, into the checkout (default `cassis/AGENTS.md`). It is a managed file (generated banner; the CLI overwrites local edits) so a repo-aware coding agent loads current Cassis modeling doctrine by convention. It sits inside the context directory but is not part of the context tree (which is the YAML files plus the domain Markdown files `domains/**/README.md`), so it is never uploaded, validated, or pruned. Commit it alongside your context changes. The guide text ships inside the CLI package, so its version tracks the **installed cassis-cli version**: upgrade the CLI (`pip install -U cassis-cli`) and re-run `fmt` to pick up doctrine updates; an unpinned `pip install cassis-cli` in CI gets them automatically. The banner stamps a doctrine version, and the CLI never *downgrades* the file: if the checkout's `AGENTS.md` was written by a newer doctrine (a newer CLI, or Cassis itself on a publish), `fmt`/`pull` leave it in place, print an upgrade notice, and `fmt --check` still passes.
|
|
11
11
|
- The CLI identifies itself to the API (`User-Agent: cassis-cli/<version>`), and successful API responses advertise the newest published version. When you are behind, commands print a one-line upgrade notice on stderr (purely informational; output and exit codes are unchanged).
|
|
@@ -375,7 +375,13 @@ def upload(
|
|
|
375
375
|
f"{result['join_count']} joins, {result['metric_count']} metrics"
|
|
376
376
|
)
|
|
377
377
|
version = result.get("published_version")
|
|
378
|
-
if version is not None:
|
|
378
|
+
if version is not None and result.get("unchanged"):
|
|
379
|
+
typer.secho(
|
|
380
|
+
f"✓ Context uploaded ({counts}). No change: v{version} stays published, "
|
|
381
|
+
f"and now records commit {head[:9]}.",
|
|
382
|
+
fg=typer.colors.GREEN,
|
|
383
|
+
)
|
|
384
|
+
elif version is not None:
|
|
379
385
|
typer.secho(f"✓ Context uploaded and published as v{version} ({counts}).", fg=typer.colors.GREEN)
|
|
380
386
|
else:
|
|
381
387
|
typer.secho(
|
|
@@ -71,12 +71,25 @@ def _local_comparison(path: Path, head: Optional[str], published_sha: Optional[s
|
|
|
71
71
|
return f"diverged from the published commit {published_sha[:9]}", False
|
|
72
72
|
|
|
73
73
|
|
|
74
|
+
def _published_commit(published: "dict[str, Any]") -> Optional[str]:
|
|
75
|
+
"""The newest commit known to hold the published content.
|
|
76
|
+
|
|
77
|
+
An upload that changes nothing publishes no version but moves
|
|
78
|
+
`latest_git_commit_sha` forward. Servers older than that field only send
|
|
79
|
+
`git_commit_sha`, the commit the version was published from.
|
|
80
|
+
"""
|
|
81
|
+
return published.get("latest_git_commit_sha") or published.get("git_commit_sha")
|
|
82
|
+
|
|
83
|
+
|
|
74
84
|
def _render(status_record: "dict[str, Any]", comparison_text: str) -> None:
|
|
75
85
|
published = status_record.get("published_version")
|
|
76
86
|
if published:
|
|
77
87
|
label = f" {published['label']!r}" if published.get("label") else ""
|
|
78
88
|
sha = published.get("git_commit_sha")
|
|
89
|
+
latest = _published_commit(published)
|
|
79
90
|
sha_text = f", commit {sha[:9]}" if sha else ""
|
|
91
|
+
if latest and latest != sha:
|
|
92
|
+
sha_text += f", unchanged at {latest[:9]}"
|
|
80
93
|
typer.echo(f"Published: v{published['version']}{label} ({published.get('published_at')}{sha_text})")
|
|
81
94
|
else:
|
|
82
95
|
typer.echo("Published: nothing yet")
|
|
@@ -164,7 +177,7 @@ def status(
|
|
|
164
177
|
"""The status record plus the local comparison it implies: (record, comparison_text, in_sync)."""
|
|
165
178
|
record = get_project_status(api_url=api_url, api_key=api_key, project_id=project_id)
|
|
166
179
|
published = record.get("published_version") or {}
|
|
167
|
-
comparison_text, in_sync = _local_comparison(path, head, published
|
|
180
|
+
comparison_text, in_sync = _local_comparison(path, head, _published_commit(published))
|
|
168
181
|
return record, comparison_text, in_sync
|
|
169
182
|
|
|
170
183
|
def report(snapshot: "Tuple[dict[str, Any], str, bool]") -> None:
|
|
@@ -175,7 +188,7 @@ def status(
|
|
|
175
188
|
_render(record, comparison_text)
|
|
176
189
|
else:
|
|
177
190
|
published = record.get("published_version") or {}
|
|
178
|
-
published_sha = published
|
|
191
|
+
published_sha = _published_commit(published)
|
|
179
192
|
version_text = f"v{published['version']}" if published else "nothing published"
|
|
180
193
|
line = f"{version_text} (commit {published_sha[:9] if published_sha else 'none'}); local: {comparison_text}"
|
|
181
194
|
if line != last_line["text"]:
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|