tangle-cli 0.1.6__tar.gz → 0.1.9__tar.gz

{tangle_cli-0.1.6 → tangle_cli-0.1.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: tangle-cli
-Version: 0.1.6
+Version: 0.1.9
 Summary: CLI for Tangle, the open-source ML pipeline orchestration platform
 Author: Alexey Volkov, Tangle authors, Volv Grebennikov
 Author-email: Alexey Volkov <alexey.volkov@ark-kun.com>, Volv Grebennikov <volv.grebennikov@shopify.com>
@@ -86,6 +86,57 @@ API-backed commands commonly accept these options. Explicit CLI options win over
 | `--config` | YAML/JSON defaults. Many commands accept a single object, a list of objects, or `_defaults` + `configs`. |
 | `--log-type` | SDK progress logs: `console`, `none`, or `file`. Logs go to stderr or a temp log file so structured stdout stays parseable. |
 | `TANGLE_VERBOSE=1` | Redacted HTTP request/response diagnostics only. This is separate from normal progress logging. |
+| `--ca-bundle` | Global CLI flag: path to a PEM CA bundle used as the TLS trust store for every transport. Overrides `TANGLE_API_CA_BUNDLE`. Place before the subcommand. |
+| `--verify-tls` / `--no-verify-tls` | Global CLI flag: enable or disable TLS verification for every transport. Overrides `TANGLE_API_VERIFY_TLS`. `--no-verify-tls` is local-development only. Place before the subcommand. |
+| `TANGLE_API_CA_BUNDLE` | Path to a PEM CA bundle used to verify TLS for every transport. Use this to trust a private or corporate CA without disabling verification. |
+| `TANGLE_API_VERIFY_TLS` | TLS verification toggle. Values `0`, `false`, or `no` (case/space-insensitive) disable verification; any other nonempty value keeps it on. |
+
+### TLS verification
+
+TLS certificate verification is enabled by default for all HTTP transports (schema
+fetches, `tangle api` calls, and the programmatic clients). The effective setting is
+resolved with the following precedence, highest to lowest:
+
+1. An explicit `verify=` argument to the Python clients (a `bool` or a path to a CA bundle).
+2. The global CLI flags `--ca-bundle` / `--verify-tls` / `--no-verify-tls`.
+3. `TANGLE_API_CA_BUNDLE` — verify against the given CA bundle.
+4. `TANGLE_API_VERIFY_TLS` — enable or disable verification.
+5. The secure default: verification enabled against the system trust store.
+
+The global CLI flags are true root options that apply to every command — the static
+`tangle sdk ...` clients, the dynamic `tangle api ...` commands, and `tangle api refresh`.
+Place them **before** the subcommand, for example `tangle --ca-bundle ca.pem api ...` or
+`tangle --no-verify-tls sdk ...`. They are honored even by the dynamic OpenAPI schema
+discovery that runs before command dispatch. A defaulted (absent) flag does not override
+the environment: when a flag is not supplied, the `TANGLE_API_*` variables and the standard
+`REQUESTS_CA_BUNDLE` / `CURL_CA_BUNDLE` handling still apply. `--ca-bundle` combined with an
+explicit `--no-verify-tls` is contradictory and fails fast before any request; `--ca-bundle`
+with `--verify-tls` is redundant but accepted.
+
+If both env vars are set, `TANGLE_API_CA_BUNDLE` wins and TLS stays verified against the
+bundle. Empty values are treated as unset. A `--ca-bundle` or `TANGLE_API_CA_BUNDLE` that
+does not point to an existing file fails fast with an actionable error before any request is
+made. When no Tangle-specific setting is provided, the standard `REQUESTS_CA_BUNDLE` /
+`CURL_CA_BUNDLE` handling and any caller-supplied `requests.Session.verify` are left
+untouched.
+
+For a private CA, prefer `--ca-bundle` / `TANGLE_API_CA_BUNDLE` over disabling verification:
+it keeps certificates verified against a trusted root. `--no-verify-tls` /
+`TANGLE_API_VERIFY_TLS=0` disables verification entirely and is intended for local
+development only — never use it against production endpoints.
+
+```bash
+# Trust a private CA with the global flag (recommended for internal/self-hosted APIs)
+uv run tangle --ca-bundle /etc/ssl/private-ca.pem \
+  api refresh --base-url https://internal.example
+
+# Or via environment variable
+TANGLE_API_CA_BUNDLE=/etc/ssl/private-ca.pem \
+  uv run tangle api refresh --base-url https://internal.example
+
+# Disable verification (local development only)
+uv run tangle --no-verify-tls api refresh --base-url https://localhost:8443
+```
 
 Examples for protected APIs:
 
@@ -317,7 +368,171 @@ uv run tangle sdk pipeline-runs annotations set RUN_ID key value
 uv run tangle sdk pipeline-runs export RUN_ID --output pipeline.yaml
 ```
 
-`pipelines validate` checks local graph shape, the packaged Tangle pipeline JSON schema, and component input wiring when component specs are present. It does not hydrate refs; validate a hydrated file when you need fully resolved component-input checks for remote refs.
+#### Python pipeline authoring
+
+Python-authored pipelines live in normal `.py` files and compile with:
+
+```bash
+uv run tangle sdk pipelines compile pipeline.py -o pipeline.yaml
+uv run tangle sdk pipelines compile pipeline.py -o pipeline.yaml --pipeline pipeline_fn_name
+```
+
+A minimal graph uses `@pipeline` for the graph and `@task` for local Python components. `@task` functions are not executed at compile time; the compiler records call sites, emits a sibling `<output>.components.yaml` with `local_from_python` entries, and rewrites task component refs to that sidecar. Hydrate later regenerates the same component YAML from the Python source.
+
+```python
+from cloud_pipelines import components
+from tangle_cli.python_pipeline import In, Out, pipeline, task
+
+
+@task(image="python:3.12")
+def write_greeting(out: components.OutputPath("Text"), who: str, greeting: str = "hello"):
+    with open(out, "w") as fh:
+        fh.write(f"{greeting} {who}")
+
+
+@pipeline("Greeting pipeline", output_name="greeting_file")
+def greeting_pipeline(who: In[str], cfg) -> Out[str]:
+    greeting = write_greeting(who=who, greeting=cfg.greeting)
+    return greeting.out
+```
+
+`In[T]` parameters become runtime graph inputs. A single `-> Out[T]` return exposes one graph output; use `@pipeline(output_name=...)` to name that output. For multiple outputs, define a frozen dataclass subclass of `Outputs` with `Out[T]` fields and return an instance. A pipeline that accepts a `cfg` parameter reads `config.yaml` (or the path passed via `@pipeline(config="...")`) at compile time, with `--override key=value` values overlaid by the compile command.
+
+Task IDs default from the left-hand variable name at the call site, converted to title case. If there is no simple left-hand variable, or if you want a stable explicit label, call `.named("Task Id")` before invoking the task. Use `.bind(...)` to pre-fill task arguments and `.with_annotations({...})` to add per-task annotations.
+
+##### Conditional task execution
+
+Pipeline inputs used as conditions are ordinary `In[str]` values; there is no special conditional input annotation. Pass the value through the reserved task-call metadata keyword `is_enabled=`:
+
+```python
+@pipeline("Conditional greeting")
+def conditional_greeting(enabled: In[str]) -> Out[str]:
+    greeting = write_greeting(who="world", is_enabled=enabled)
+    return greeting.out
+```
+
+This emits the canonical task field rather than a component argument:
+
+```yaml
+isEnabled:
+  graphInput:
+    inputName: enabled
+```
+
+`is_enabled=` supports Python booleans (serialized as lowercase `"true"` / `"false"` strings), string constants, `In[...]` graph inputs, and previous task outputs such as `is_enabled=gate.Output`. It is container-component task metadata; component function parameters are not implicitly conditions.
+
+If a component itself declares an input named `is_enabled`, bind that component argument separately while using the call-site keyword for task metadata:
+
+```python
+@task(image="python:3.12")
+def work(is_enabled: str, message: str) -> str:
+    return message
+
+@pipeline("Input-name collision")
+def collision(runtime_condition: In[str]) -> Out[str]:
+    result = work.bind(is_enabled="component-input-value")(
+        message="hello",
+        is_enabled=runtime_condition,
+    )
+    return result.Output
+```
+
+The bound value remains under `arguments.is_enabled`; the call-site value emits as `isEnabled`. Tangle does not evaluate conditions on graph-component tasks, so `subpipeline(...)(is_enabled=...)` is rejected with guidance to condition tasks inside the child pipeline. A child graph input with that name remains available through `subpipeline(...).bind(is_enabled=...)(...)`. There is no `condition` alias.
+
+##### Task images, dependencies, and image IDs
+
+Use `@task(image="...")` to write the component image directly. Use `dependencies_from="pyproject.toml"` when generated components need to install Python dependencies. Several tasks can share one authoring-only `TaskEnv`:
+
+```python
+from tangle_cli.python_pipeline import TaskEnv, task
+
+EVAL = TaskEnv(image="python:3.12", dependencies_from="pyproject.toml")
+
+@task(env=EVAL)
+def score(...):
+    ...
+```
+
+Use `@task(image_id="eval-slim")` when source should carry a logical image name instead of a concrete registry reference. Downstream code can register defaults with `register_image_id(...)`, and callers can override at compile time with repeatable `--image ID=REF`:
+
+```bash
+uv run tangle sdk pipelines compile pipeline.py -o pipeline.yaml \
+  --image eval-slim=registry.example/eval-slim@sha256:...
+```
+
+An explicit `image="..."` wins over `image_id=...`. If an `image_id` has neither a registered default nor a `--image` override, compile fails.
+
+##### Subpipelines and existing components
+
+Use `subpipeline(child_pipeline)(...)` to call another Python `@pipeline` as one task in a parent graph. The child compiles to a subgraph sidecar under `<output>.subgraphs/`, and the returned handle exposes the child pipeline's declared outputs.
+
+```python
+from tangle_cli.python_pipeline import In, Out, pipeline, subpipeline
+
+@pipeline("Child")
+def child(seed: In[str]) -> Out[str]:
+    ...
+
+@pipeline("Parent")
+def parent(seed: In[str]) -> Out[str]:
+    child_result = subpipeline(child).named("Run child")(seed=seed)
+    return child_result.wait_for_output
+```
+
+Use `ref(url=...)`, `ref(name=...)`, or `ref(digest=...)` to call an existing component YAML or published component instead of authoring a local `@task`. Use `@registered(fragment=..., gen_config=...)` for operation wrappers that are already present in an existing `gen_config.yaml`; the compiler rewrites those calls to `resolve://...#fragment` without generating a new sidecar.
+
+##### Dynamic arguments and runtime placeholders
+
+Task argument values can be literals, graph inputs, task outputs, or supported dynamic data. Use `dynamic_secret("NAME")` to emit a runtime secret reference:
+
+```python
+from tangle_cli.python_pipeline import dynamic_secret
+
+call_api(api_key=dynamic_secret("OPENAI_API_KEY"))
+```
+
+Use `raw("...")` only for string values that intentionally contain a `{{name}}` runtime placeholder substituted by the component itself. `raw()` is not a compile-time Jinja escape hatch; `{% ... %}` and `{# ... #}` are rejected.
+
+##### Unwrapped dict task inputs
+
+Python-authored pipelines can mark one or more `dict[str, T]` task parameters for unwrapping:
+
+```python
+from cloud_pipelines import components
+from tangle_cli.python_pipeline import Out, pipeline, task
+
+
+@task(image="python:3.12")
+def make_greeting(name: str) -> str:
+    return f"hello {name}"
+
+
+@task(image="python:3.12", unwrap="items")
+def join_greetings(out: components.OutputPath("Text"), items: dict[str, str], prefix: str = "joined"):
+    with open(out, "w") as fh:
+        fh.write(f"{prefix}: " + " | ".join(items[key] for key in sorted(items)))
+
+
+@pipeline("Greeting pipeline")
+def greeting_pipeline() -> Out[str]:
+    world = make_greeting.named("world_source")(name="world")
+    tangle = make_greeting.named("tangle_source")(name="tangle")
+    joined = join_greetings.named("join")(
+        prefix="demo",
+        items={
+            "who_1": world.Output,
+            "who_2": tangle.Output,
+            "literal": "plain value",
+        },
+    )
+    return joined.out
+```
+
+`unwrap="items"` tells the compiler that the caller-provided entries in `items` should become explicit component inputs. The call above compiles the consumer task arguments as `items__who_1`, `items__who_2`, and `items__literal`; task-output values remain normal graph edges and literal values remain literals. The generated components sidecar persists the exact flattened schema under `local_from_python.unwrapped_inputs`, including the generated input names and inferred value type. Hydrate passes that schema back into Python component generation so the regenerated component has the same flattened inputs even though hydrate no longer has access to the original Python call-site dict. The generated runtime wrapper then re-wraps those CLI arguments back into the original `items` dict before calling `join_greetings(...)`.
+
+Use `unwrap=["items", "metadata"]` to unwrap multiple dict parameters. The caller owns the key names; keys may contain letters, numbers, `_`, and `-`, and become `param__<key>` component inputs. Empty dicts are rejected because they do not define a component interface. If a generated name would collide with a fixed parameter or another generated name, compile fails before writing artifacts. Equivalent key sets are canonicalized for schema hashing, so two call sites with the same keys in different insertion orders dedupe to the same component fragment.
+
+#### Pipeline run submission and validation
 
 `submit` hydrates refs by default and builds an API submit payload with `root_task.componentRef.spec`. Use `--no-hydrate` to submit the local YAML structure as-is. Use `--dry-run` to print the payload without creating a run.
 

{tangle_cli-0.1.6 → tangle_cli-0.1.9}/README.md

@@ -60,6 +60,57 @@ API-backed commands commonly accept these options. Explicit CLI options win over
 | `--config` | YAML/JSON defaults. Many commands accept a single object, a list of objects, or `_defaults` + `configs`. |
 | `--log-type` | SDK progress logs: `console`, `none`, or `file`. Logs go to stderr or a temp log file so structured stdout stays parseable. |
 | `TANGLE_VERBOSE=1` | Redacted HTTP request/response diagnostics only. This is separate from normal progress logging. |
+| `--ca-bundle` | Global CLI flag: path to a PEM CA bundle used as the TLS trust store for every transport. Overrides `TANGLE_API_CA_BUNDLE`. Place before the subcommand. |
+| `--verify-tls` / `--no-verify-tls` | Global CLI flag: enable or disable TLS verification for every transport. Overrides `TANGLE_API_VERIFY_TLS`. `--no-verify-tls` is local-development only. Place before the subcommand. |
+| `TANGLE_API_CA_BUNDLE` | Path to a PEM CA bundle used to verify TLS for every transport. Use this to trust a private or corporate CA without disabling verification. |
+| `TANGLE_API_VERIFY_TLS` | TLS verification toggle. Values `0`, `false`, or `no` (case/space-insensitive) disable verification; any other nonempty value keeps it on. |
+
+### TLS verification
+
+TLS certificate verification is enabled by default for all HTTP transports (schema
+fetches, `tangle api` calls, and the programmatic clients). The effective setting is
+resolved with the following precedence, highest to lowest:
+
+1. An explicit `verify=` argument to the Python clients (a `bool` or a path to a CA bundle).
+2. The global CLI flags `--ca-bundle` / `--verify-tls` / `--no-verify-tls`.
+3. `TANGLE_API_CA_BUNDLE` — verify against the given CA bundle.
+4. `TANGLE_API_VERIFY_TLS` — enable or disable verification.
+5. The secure default: verification enabled against the system trust store.
+
+The global CLI flags are true root options that apply to every command — the static
+`tangle sdk ...` clients, the dynamic `tangle api ...` commands, and `tangle api refresh`.
+Place them **before** the subcommand, for example `tangle --ca-bundle ca.pem api ...` or
+`tangle --no-verify-tls sdk ...`. They are honored even by the dynamic OpenAPI schema
+discovery that runs before command dispatch. A defaulted (absent) flag does not override
+the environment: when a flag is not supplied, the `TANGLE_API_*` variables and the standard
+`REQUESTS_CA_BUNDLE` / `CURL_CA_BUNDLE` handling still apply. `--ca-bundle` combined with an
+explicit `--no-verify-tls` is contradictory and fails fast before any request; `--ca-bundle`
+with `--verify-tls` is redundant but accepted.
+
+If both env vars are set, `TANGLE_API_CA_BUNDLE` wins and TLS stays verified against the
+bundle. Empty values are treated as unset. A `--ca-bundle` or `TANGLE_API_CA_BUNDLE` that
+does not point to an existing file fails fast with an actionable error before any request is
+made. When no Tangle-specific setting is provided, the standard `REQUESTS_CA_BUNDLE` /
+`CURL_CA_BUNDLE` handling and any caller-supplied `requests.Session.verify` are left
+untouched.
+
+For a private CA, prefer `--ca-bundle` / `TANGLE_API_CA_BUNDLE` over disabling verification:
+it keeps certificates verified against a trusted root. `--no-verify-tls` /
+`TANGLE_API_VERIFY_TLS=0` disables verification entirely and is intended for local
+development only — never use it against production endpoints.
+
+```bash
+# Trust a private CA with the global flag (recommended for internal/self-hosted APIs)
+uv run tangle --ca-bundle /etc/ssl/private-ca.pem \
+  api refresh --base-url https://internal.example
+
+# Or via environment variable
+TANGLE_API_CA_BUNDLE=/etc/ssl/private-ca.pem \
+  uv run tangle api refresh --base-url https://internal.example
+
+# Disable verification (local development only)
+uv run tangle --no-verify-tls api refresh --base-url https://localhost:8443
+```
 
 Examples for protected APIs:
 
@@ -291,7 +342,171 @@ uv run tangle sdk pipeline-runs annotations set RUN_ID key value
 uv run tangle sdk pipeline-runs export RUN_ID --output pipeline.yaml
 ```
 
-`pipelines validate` checks local graph shape, the packaged Tangle pipeline JSON schema, and component input wiring when component specs are present. It does not hydrate refs; validate a hydrated file when you need fully resolved component-input checks for remote refs.
+#### Python pipeline authoring
+
+Python-authored pipelines live in normal `.py` files and compile with:
+
+```bash
+uv run tangle sdk pipelines compile pipeline.py -o pipeline.yaml
+uv run tangle sdk pipelines compile pipeline.py -o pipeline.yaml --pipeline pipeline_fn_name
+```
+
+A minimal graph uses `@pipeline` for the graph and `@task` for local Python components. `@task` functions are not executed at compile time; the compiler records call sites, emits a sibling `<output>.components.yaml` with `local_from_python` entries, and rewrites task component refs to that sidecar. Hydrate later regenerates the same component YAML from the Python source.
+
+```python
+from cloud_pipelines import components
+from tangle_cli.python_pipeline import In, Out, pipeline, task
+
+
+@task(image="python:3.12")
+def write_greeting(out: components.OutputPath("Text"), who: str, greeting: str = "hello"):
+    with open(out, "w") as fh:
+        fh.write(f"{greeting} {who}")
+
+
+@pipeline("Greeting pipeline", output_name="greeting_file")
+def greeting_pipeline(who: In[str], cfg) -> Out[str]:
+    greeting = write_greeting(who=who, greeting=cfg.greeting)
+    return greeting.out
+```
+
+`In[T]` parameters become runtime graph inputs. A single `-> Out[T]` return exposes one graph output; use `@pipeline(output_name=...)` to name that output. For multiple outputs, define a frozen dataclass subclass of `Outputs` with `Out[T]` fields and return an instance. A pipeline that accepts a `cfg` parameter reads `config.yaml` (or the path passed via `@pipeline(config="...")`) at compile time, with `--override key=value` values overlaid by the compile command.
+
+Task IDs default from the left-hand variable name at the call site, converted to title case. If there is no simple left-hand variable, or if you want a stable explicit label, call `.named("Task Id")` before invoking the task. Use `.bind(...)` to pre-fill task arguments and `.with_annotations({...})` to add per-task annotations.
+
+##### Conditional task execution
+
+Pipeline inputs used as conditions are ordinary `In[str]` values; there is no special conditional input annotation. Pass the value through the reserved task-call metadata keyword `is_enabled=`:
+
+```python
+@pipeline("Conditional greeting")
+def conditional_greeting(enabled: In[str]) -> Out[str]:
+    greeting = write_greeting(who="world", is_enabled=enabled)
+    return greeting.out
+```
+
+This emits the canonical task field rather than a component argument:
+
+```yaml
+isEnabled:
+  graphInput:
+    inputName: enabled
+```
+
+`is_enabled=` supports Python booleans (serialized as lowercase `"true"` / `"false"` strings), string constants, `In[...]` graph inputs, and previous task outputs such as `is_enabled=gate.Output`. It is container-component task metadata; component function parameters are not implicitly conditions.
+
+If a component itself declares an input named `is_enabled`, bind that component argument separately while using the call-site keyword for task metadata:
+
+```python
+@task(image="python:3.12")
+def work(is_enabled: str, message: str) -> str:
+    return message
+
+@pipeline("Input-name collision")
+def collision(runtime_condition: In[str]) -> Out[str]:
+    result = work.bind(is_enabled="component-input-value")(
+        message="hello",
+        is_enabled=runtime_condition,
+    )
+    return result.Output
+```
+
+The bound value remains under `arguments.is_enabled`; the call-site value emits as `isEnabled`. Tangle does not evaluate conditions on graph-component tasks, so `subpipeline(...)(is_enabled=...)` is rejected with guidance to condition tasks inside the child pipeline. A child graph input with that name remains available through `subpipeline(...).bind(is_enabled=...)(...)`. There is no `condition` alias.
+
+##### Task images, dependencies, and image IDs
+
+Use `@task(image="...")` to write the component image directly. Use `dependencies_from="pyproject.toml"` when generated components need to install Python dependencies. Several tasks can share one authoring-only `TaskEnv`:
+
+```python
+from tangle_cli.python_pipeline import TaskEnv, task
+
+EVAL = TaskEnv(image="python:3.12", dependencies_from="pyproject.toml")
+
+@task(env=EVAL)
+def score(...):
+    ...
+```
+
+Use `@task(image_id="eval-slim")` when source should carry a logical image name instead of a concrete registry reference. Downstream code can register defaults with `register_image_id(...)`, and callers can override at compile time with repeatable `--image ID=REF`:
+
+```bash
+uv run tangle sdk pipelines compile pipeline.py -o pipeline.yaml \
+  --image eval-slim=registry.example/eval-slim@sha256:...
+```
+
+An explicit `image="..."` wins over `image_id=...`. If an `image_id` has neither a registered default nor a `--image` override, compile fails.
+
+##### Subpipelines and existing components
+
+Use `subpipeline(child_pipeline)(...)` to call another Python `@pipeline` as one task in a parent graph. The child compiles to a subgraph sidecar under `<output>.subgraphs/`, and the returned handle exposes the child pipeline's declared outputs.
+
+```python
+from tangle_cli.python_pipeline import In, Out, pipeline, subpipeline
+
+@pipeline("Child")
+def child(seed: In[str]) -> Out[str]:
+    ...
+
+@pipeline("Parent")
+def parent(seed: In[str]) -> Out[str]:
+    child_result = subpipeline(child).named("Run child")(seed=seed)
+    return child_result.wait_for_output
+```
+
+Use `ref(url=...)`, `ref(name=...)`, or `ref(digest=...)` to call an existing component YAML or published component instead of authoring a local `@task`. Use `@registered(fragment=..., gen_config=...)` for operation wrappers that are already present in an existing `gen_config.yaml`; the compiler rewrites those calls to `resolve://...#fragment` without generating a new sidecar.
+
+##### Dynamic arguments and runtime placeholders
+
+Task argument values can be literals, graph inputs, task outputs, or supported dynamic data. Use `dynamic_secret("NAME")` to emit a runtime secret reference:
+
+```python
+from tangle_cli.python_pipeline import dynamic_secret
+
+call_api(api_key=dynamic_secret("OPENAI_API_KEY"))
+```
+
+Use `raw("...")` only for string values that intentionally contain a `{{name}}` runtime placeholder substituted by the component itself. `raw()` is not a compile-time Jinja escape hatch; `{% ... %}` and `{# ... #}` are rejected.
+
+##### Unwrapped dict task inputs
+
+Python-authored pipelines can mark one or more `dict[str, T]` task parameters for unwrapping:
+
+```python
+from cloud_pipelines import components
+from tangle_cli.python_pipeline import Out, pipeline, task
+
+
+@task(image="python:3.12")
+def make_greeting(name: str) -> str:
+    return f"hello {name}"
+
+
+@task(image="python:3.12", unwrap="items")
+def join_greetings(out: components.OutputPath("Text"), items: dict[str, str], prefix: str = "joined"):
+    with open(out, "w") as fh:
+        fh.write(f"{prefix}: " + " | ".join(items[key] for key in sorted(items)))
+
+
+@pipeline("Greeting pipeline")
+def greeting_pipeline() -> Out[str]:
+    world = make_greeting.named("world_source")(name="world")
+    tangle = make_greeting.named("tangle_source")(name="tangle")
+    joined = join_greetings.named("join")(
+        prefix="demo",
+        items={
+            "who_1": world.Output,
+            "who_2": tangle.Output,
+            "literal": "plain value",
+        },
+    )
+    return joined.out
+```
+
+`unwrap="items"` tells the compiler that the caller-provided entries in `items` should become explicit component inputs. The call above compiles the consumer task arguments as `items__who_1`, `items__who_2`, and `items__literal`; task-output values remain normal graph edges and literal values remain literals. The generated components sidecar persists the exact flattened schema under `local_from_python.unwrapped_inputs`, including the generated input names and inferred value type. Hydrate passes that schema back into Python component generation so the regenerated component has the same flattened inputs even though hydrate no longer has access to the original Python call-site dict. The generated runtime wrapper then re-wraps those CLI arguments back into the original `items` dict before calling `join_greetings(...)`.
+
+Use `unwrap=["items", "metadata"]` to unwrap multiple dict parameters. The caller owns the key names; keys may contain letters, numbers, `_`, and `-`, and become `param__<key>` component inputs. Empty dicts are rejected because they do not define a component interface. If a generated name would collide with a fixed parameter or another generated name, compile fails before writing artifacts. Equivalent key sets are canonicalized for schema hashing, so two call sites with the same keys in different insertion orders dedupe to the same component fragment.
+
+#### Pipeline run submission and validation
 
 `submit` hydrates refs by default and builds an API submit payload with `root_task.componentRef.spec`. Use `--no-hydrate` to submit the local YAML structure as-is. Use `--dry-run` to print the payload without creating a run.
 

{tangle_cli-0.1.6 → tangle_cli-0.1.9}/packages/tangle-cli/src/tangle_cli/__init__.py

@@ -14,6 +14,6 @@ from tangle_cli.dynamic_discovery_client import TangleDynamicDiscoveryClient
 try:
     __version__ = metadata_version("tangle-cli")
 except PackageNotFoundError:
-    __version__ = "0.1.6"
+    __version__ = "0.1.9"
 
 __all__ = ["TangleDynamicDiscoveryClient", "__version__"]

{tangle_cli-0.1.6 → tangle_cli-0.1.9}/packages/tangle-cli/src/tangle_cli/api_cli.py

@@ -640,10 +640,22 @@ def _argv_dispatches_dynamic_command(argv: list[str]) -> bool:
 
 
 def _api_argv_tail(argv: list[str]) -> list[str] | None:
-    """Return args after the root `api` command, or None for non-API invocations."""
+    """Return args after the root `api` command, or None for non-API invocations.
+
+    Global TLS flags (``--ca-bundle``/``--verify-tls``/``--no-verify-tls``) may
+    precede the subcommand, so they are skipped before locating `api`.
+    """
 
     args = list(argv[1:])
-    for index, arg in enumerate(args):
+    index = 0
+    while index < len(args):
+        arg = args[index]
+        if arg == "--ca-bundle" and index + 1 < len(args):
+            index += 2
+            continue
+        if arg.startswith("--ca-bundle=") or arg in {"--verify-tls", "--no-verify-tls"}:
+            index += 1
+            continue
         if arg == "--":
             if index + 1 < len(args) and args[index + 1] == "api":
                 return args[index + 2 :]

{tangle_cli-0.1.6 → tangle_cli-0.1.9}/packages/tangle-cli/src/tangle_cli/api_schema.py

@@ -18,7 +18,9 @@ from .api_transport import (
     _normalize_base_url,
     _openapi_url,
     _request_headers,
+    _VERIFY_UNSET,
     default_base_url,
+    httpx_verify,
 )
 
 SUPPORTED_METHODS = {"get", "post", "put", "patch", "delete"}
@@ -122,6 +124,7 @@ def fetch_schema(
     auth_header: str | None = None,
     headers: dict[str, str] | None = None,
     include_env_credentials: bool = True,
+    verify: Any = _VERIFY_UNSET,
 ) -> dict[str, Any]:
     """Fetch ``/openapi.json``, applying bearer and custom auth headers."""
 
@@ -136,6 +139,7 @@ def fetch_schema(
             include_env_credentials=include_env_credentials,
         ),
         timeout=DEFAULT_TIMEOUT_SECONDS,
+        verify=httpx_verify(verify),
     )
     response.raise_for_status()
     payload = response.text
@@ -152,6 +156,7 @@ def refresh_schema(
     auth_header: str | None = None,
     headers: dict[str, str] | None = None,
     include_env_credentials: bool = True,
+    verify: Any = _VERIFY_UNSET,
 ) -> tuple[dict[str, Any], Path]:
     """Fetch and cache the latest schema for a backend."""
 
@@ -163,6 +168,7 @@ def refresh_schema(
         auth_header,
         headers,
         include_env_credentials=include_env_credentials,
+        verify=verify,
     )
     path = write_cached_schema(schema, base_url)
     return schema, path
@@ -175,6 +181,7 @@ def load_or_fetch_schema(
     auth_header: str | None = None,
     headers: dict[str, str] | None = None,
     include_env_credentials: bool = True,
+    verify: Any = _VERIFY_UNSET,
 ) -> dict[str, Any]:
     """Use a cached schema when available, otherwise fetch once and cache it."""
 
@@ -188,6 +195,7 @@ def load_or_fetch_schema(
         auth_header,
         headers,
         include_env_credentials=include_env_credentials,
+        verify=verify,
     )
     return schema