composable-data-stack 0.4.0__tar.gz → 0.5.1__tar.gz

{composable_data_stack-0.4.0/composable_data_stack.egg-info → composable_data_stack-0.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: composable-data-stack
-Version: 0.4.0
+Version: 0.5.1
 Summary: CLI for validating and composing composable data stack profiles
 Author: Ronald Hensbergen
 License-Expression: Apache-2.0
@@ -31,7 +31,7 @@ Provides-Extra: dev
 Requires-Dist: coverage>=7.6; extra == "dev"
 Requires-Dist: bandit>=1.7; extra == "dev"
 Requires-Dist: pip-audit>=2.7; extra == "dev"
-Requires-Dist: ruff==0.16.2; extra == "dev"
+Requires-Dist: ruff==0.16.4; extra == "dev"
 Dynamic: license-file
 
 # 🚀 Composable Data Stack (CDS)
@@ -55,6 +55,10 @@ Composable Data Stack (CDS) is a framework for defining and assembling data plat
 
 > **Note:** Development helper tools are located in the `tools/` directory (git-ignored). See `tools/pr-cli/README.md` for PR creation scripts.
 
+---
+
+## ⚡ Why CDS
+
 Instead of hardcoding integrations or relying on fragile pipelines, CDS introduces:
 
 - 🔧 **Modules**: reusable components (Dagster, Postgres, Superset)
@@ -63,10 +67,6 @@ Instead of hardcoding integrations or relying on fragile pipelines, CDS introduc
 
 Think of it as Infrastructure as Code, but for data platforms.
 
----
-
-## ⚡ Why CDS
-
 Modern data platforms force a trade-off:
 
 |Approach|Problem|
@@ -642,6 +642,7 @@ before and never look for an `environments/` directory.
 
 |Command|Description|
 |---|---|
+|cds get \<profile\> [--remote \<owner/repo\>] [--ref \<ref\>] [--local \<dir\>] [--into \<dir\>]|Fetch a profile plus its dependent module/runtime assets from GitHub into a local CDS layout|
 |cds init [profile]|Generate a project `.env` template from profile secret definitions|
 |cds validate [profile]|Validate modules and contracts|
 |cds preflight [profile]|Check runtime tools, required environment values, and host ports without starting services|
@@ -660,6 +661,19 @@ all accept `--environment <name>` (or `-e <name>`) to merge
 `environments/<name>.yaml` over the base profile before resolving; see
 [Environment Overlays](#environment-overlays).
 
+`cds get` copies the selected `profiles/<name>/` tree, every referenced module
+directory, and any local build-context assets referenced by those modules'
+Dockerfiles. By design it downloads from GitHub rather than a local checkout:
+by default it fetches this project's upstream repository at the `main` branch,
+downloading a tarball via the GitHub API (no `git` binary required). Use
+`--remote <owner/repo>` (or a `github.com/...` URL) to fetch a fork, and
+`--ref <branch|tag|sha>` to select a specific revision. Pass `--local <dir>`
+to use an existing local directory instead of downloading (mutually exclusive
+with `--remote`/`--ref`) for offline/dev workflows. Use `--into` to choose a
+destination root, `--dry-run` to inspect the copy plan first, and `--force` to
+replace conflicting local files. Successful fetches record tracking metadata
+in `.cds/get-manifest.json` for future update workflows.
+
 `[profile]` accepts:
 
 | Form | Example |

{composable_data_stack-0.4.0 → composable_data_stack-0.5.1}/README.md

@@ -19,6 +19,10 @@ Composable Data Stack (CDS) is a framework for defining and assembling data plat
 
 > **Note:** Development helper tools are located in the `tools/` directory (git-ignored). See `tools/pr-cli/README.md` for PR creation scripts.
 
+---
+
+## ⚡ Why CDS
+
 Instead of hardcoding integrations or relying on fragile pipelines, CDS introduces:
 
 - 🔧 **Modules**: reusable components (Dagster, Postgres, Superset)
@@ -27,10 +31,6 @@ Instead of hardcoding integrations or relying on fragile pipelines, CDS introduc
 
 Think of it as Infrastructure as Code, but for data platforms.
 
----
-
-## ⚡ Why CDS
-
 Modern data platforms force a trade-off:
 
 |Approach|Problem|
@@ -606,6 +606,7 @@ before and never look for an `environments/` directory.
 
 |Command|Description|
 |---|---|
+|cds get \<profile\> [--remote \<owner/repo\>] [--ref \<ref\>] [--local \<dir\>] [--into \<dir\>]|Fetch a profile plus its dependent module/runtime assets from GitHub into a local CDS layout|
 |cds init [profile]|Generate a project `.env` template from profile secret definitions|
 |cds validate [profile]|Validate modules and contracts|
 |cds preflight [profile]|Check runtime tools, required environment values, and host ports without starting services|
@@ -624,6 +625,19 @@ all accept `--environment <name>` (or `-e <name>`) to merge
 `environments/<name>.yaml` over the base profile before resolving; see
 [Environment Overlays](#environment-overlays).
 
+`cds get` copies the selected `profiles/<name>/` tree, every referenced module
+directory, and any local build-context assets referenced by those modules'
+Dockerfiles. By design it downloads from GitHub rather than a local checkout:
+by default it fetches this project's upstream repository at the `main` branch,
+downloading a tarball via the GitHub API (no `git` binary required). Use
+`--remote <owner/repo>` (or a `github.com/...` URL) to fetch a fork, and
+`--ref <branch|tag|sha>` to select a specific revision. Pass `--local <dir>`
+to use an existing local directory instead of downloading (mutually exclusive
+with `--remote`/`--ref`) for offline/dev workflows. Use `--into` to choose a
+destination root, `--dry-run` to inspect the copy plan first, and `--force` to
+replace conflicting local files. Successful fetches record tracking metadata
+in `.cds/get-manifest.json` for future update workflows.
+
 `[profile]` accepts:
 
 | Form | Example |

composable_data_stack-0.5.1/cli/constants.py

@@ -0,0 +1,8 @@
+# Guards recursive traversal of user-controlled YAML structures (schema
+# defaults, contract/config interpolation) against maliciously or accidentally
+# deeply nested documents that would otherwise raise an unhandled
+# RecursionError / stack overflow.
+MAX_NESTING_DEPTH = 100
+
+class MaxNestingDepthExceeded(Exception):
+    """Raised when a recursive structure exceeds MAX_NESTING_DEPTH."""