omni-train-cli 0.1.29__py3-none-any.whl

omni_cli/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.1.29"

omni_cli/__main__.py

@@ -0,0 +1,5 @@
+from .main import main
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

omni_cli/bundled_skills/omni-train/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: omni-train
+description: Use when operating Omni Train through the CLI, preparing custom image algorithm packages, or running dataset, training, deployment, and algorithm build workflows.
+---
+
+# Omni Train agent workflow
+
+Use the `omni` CLI as the only platform interface. Use `--output json` for every command and make decisions from the JSON envelope and exit code.
+
+1. Run `omni context show --output json` before platform work.
+   When the user has not selected a Workspace, keep the account's default Workspace
+   and do not persist an override. When the user asks which
+   Workspaces are available, run `omni workspace list --output json`. Only
+   switch after an explicit user request, using
+   `omni workspace use <workspace_id> --output json`; never guess a Workspace ID.
+   Restore the account default with
+   `omni workspace reset --output json`.
+2. Discover real dataset, task, and algorithm IDs with `omni dataset`, `omni task`, and `omni algorithm`; never guess IDs. Use `omni task list --page`, `--page-size`, or `--all` when the task list is paginated.
+   Use `--page`, `--page-size`, or `--all` when a list response is paginated.
+   When the user needs a new dataset, run
+   `omni dataset create --name <name> --type <type> --labels <label1,label2> --output json`
+   and retain the returned `dataset_id`. To upload a local ZIP, run
+   `omni dataset upload <archive.zip> --dataset-id <dataset_id> --subset-name <subset> --output json`.
+   This command creates the dataset subset and uses persistent TUS resumable
+   upload state. Keep resume enabled by default; use `--restart` only when the
+   user explicitly asks to discard the current upload session. File upload
+   completion is not dataset parsing completion. Use `--wait` only when the
+   user asks to wait for parsing, and report the returned upload and parse
+   states separately.
+   When the user explicitly says the ZIP contains LabelMe annotations, add
+   `--labeled-format json`. Each annotated image must have a `.json` file in
+   the same directory with the same filename stem. When a classification ZIP
+   is organized by label directory, add `--labeled-format folder`; every image
+   must be below a directory whose name exactly matches an existing dataset
+   label. The target must be a classification dataset using tag annotations.
+   A single common wrapper directory is allowed. Do not infer labeled mode
+   from ZIP contents when the user has not declared it.
+3. Read the selected algorithm's `params` from
+   `omni algorithm get <algorithm_id> --output json`, then create `train.yaml`
+   using `references/train-schema.md`. Standard training defaults are declared
+   under `params.base`. When the user does not specify `epochs`, `batch_size`,
+   or `input_size`, omit those fields instead of inventing values; the CLI
+   applies the selected algorithm's defaults. Put custom overrides under
+   `configuration.advanced_conf.<stage>` using only stages and keys declared
+   by that algorithm. Never guess a custom parameter name.
+   For `dataset.splits`, follow the split rules in `references/train-schema.md`:
+   a single subtask uses ratio split and defaults to 8:2 (`0.8`/`0.2`) when
+   `train`/`val` are omitted. With multiple subtasks, ask the user whether to
+   use ratio split (fractions on every subtask) or independent split
+   (`mode: independent` with `1`/`0`, naming which subtasks are train and which
+   are val); do not guess the strategy.
+4. Run `omni train validate --file train.yaml --output json`.
+5. Run `omni train create --file train.yaml --output json` and retain
+   `train_id`, `run_id`, and `invocation_id`.
+6. By default, create and start it without pausing for confirmation. Immediately
+   run `omni train submit --run-id <run_id> --output json` after a successful
+   creation. Only stop after creation when the user explicitly asks for
+   create-only, no start, a draft, or inspection before starting.
+7. Wait only when requested with `omni train wait <run_id>`. Do not poll indefinitely.
+8. Diagnose failures with `omni train status <run_id> --output json` and
+   `omni train logs <run_id> --log-type client --output json`. The `client`
+   log is the default and contains detailed training output such as per-epoch
+   metrics. Use `--log-type task` for workflow-stage messages and
+   `--log-type all` for a snapshot of both streams. Add `--follow` only to a
+   single `client` or `task` stream.
+9. Run `omni train stop <run_id>` only after the user explicitly asks to stop.
+10. On completion, use `omni train result <run_id>` for metrics and `omni train download` only when artifacts are requested.
+
+## Updating existing resources
+
+Use the dedicated CLI update command. The CLI follows the platform REST
+contract: algorithms, projects, and training tasks use their standard resource
+`PATCH` endpoints; only deployment configuration uses a dedicated `config`
+endpoint. Updates do not start, stop, delete, upload, rebuild, or resubmit
+anything.
+
+- Algorithm metadata: `omni algorithm update <algorithm_id> --file algorithm-update.yaml --output json`.
+  Only `name`, `description`, `type`, and `params` are editable. Use
+  `omni algorithm upload --algorithm-id` when source code changes.
+- Project metadata: `omni project update <project_id> --file project-update.yaml --output json`.
+  Only `name` and `description` are editable; project type is immutable.
+- Training configuration: `omni train update <run_id> --file train.yaml --output json`.
+  The task must still be `new`. Keep `project.train_id` and `run.type`
+  unchanged. The selected algorithm is read again so omitted base/custom
+  parameters use that algorithm's defaults. When `dataset` or `configuration`
+  is supplied, it replaces that entire nested section.
+- Deployment configuration: `omni deploy update <deploy_id> --file deploy.yaml --output json`.
+  The deployment must still be `new`. The CLI and server revalidate the
+  completed model, ONNX artifact, chip, system, framework, and quantization.
+  Deployment format remains ONNX.
+
+Always inspect the JSON returned after an update. The CLI re-fetches the
+resource so the response reflects server-authoritative values. If a training
+task or deployment has started, create a new one instead of trying to mutate
+runtime state.
+
+`omni train submit --file train.yaml --output json` remains a
+backward-compatible shortcut that creates and immediately starts a task. Use
+the explicit create-then-submit flow when the task must be inspected before
+starting.
+
+During `omni train create` and the compatible file-based submit shortcut, the
+CLI fetches the selected algorithm, fills omitted base and custom values from
+its defaults, applies the values in `train.yaml` as overrides, and validates
+types, choices, and ranges. The supported image algorithm stages are
+`dataset_preprocess`, `train`, `val`, `dataset_postprocess`, and
+`convert_onnx`. `omni train validate` is offline and checks only the file
+structure; create-time validation is authoritative for the selected algorithm.
+
+## Completed model deployment
+
+When the user asks to convert, package, or deploy a completed training model,
+**MUST read** `references/deployment.md` completely before acting.
+
+1. Run `omni deploy platforms --output json` and select only a target returned
+   by the current Workspace.
+2. Confirm the selected model is completed with
+   `omni train get <model_id> --output json`. Never deploy an unfinished model.
+3. Create `deploy.yaml` from `assets/deploy.example.yaml`. Use only the chip,
+   framework, system, quantization, and input values supported by the selected
+   platform. Never send web-only fields such as `vendor`, `vendoor`,
+   `platform`, `compiler`, or `model_name`.
+4. By default, create and start the deployment without pausing for confirmation
+   with `omni deploy submit --file deploy.yaml --output json`. Only stop after
+   creation when the user explicitly asks for create-only, no start, a draft,
+   or inspection before starting; in that case use
+   `omni deploy create --file deploy.yaml --output json`.
+5. Query `omni deploy status <deploy_id> --output json` and
+   `omni deploy logs <deploy_id> --output json`. Use
+   `omni deploy wait <deploy_id> --output json` only when the user asks to wait,
+   and never poll indefinitely.
+6. Download the completed package only when requested. When the deployment SDK
+   is requested, use
+   `omni deploy sdk <deploy_id> --output-path ./artifacts/omni-sdk.zip --output json`.
+   The deployment's stored `system` and `platform` are authoritative: never
+   invent or send target overrides for SDK download.
+7. Stop or delete a deployment only after an explicit user request. Preserve
+   failed and stopped records and their logs by default.
+
+## Custom image algorithm development
+
+When asked to generate, modify, validate, package, or troubleshoot a local
+custom image algorithm, **MUST read**
+`references/custom-image-algorithms.md` completely before acting. Treat that
+reference as the authoritative contract for entrypoints, configuration,
+LabelMe data, stage inputs and outputs, metrics, ONNX artifacts, local
+verification, packaging, and troubleshooting. Do not invent paths or rebuild
+platform-managed configuration fields.
+
+When generating a new image algorithm, follow the advisory per-epoch logging
+pattern in `references/custom-image-algorithms.md`. Skill-generated image
+algorithms should emit one progress record after every completed epoch to both
+standard output and `config["log_path"]`. This is not an upload requirement:
+do not reject, rewrite, or diagnose an independently developed algorithm only
+because its logs use another format.
+
+For Skill-generated algorithms, apply the headless image dependencies rules in
+the reference. Never generate GUI-enabled OpenCV or Ultralytics requirements
+for the platform training container.
+
+For every Skill-generated custom image algorithm, generate a separate
+`algorithm.params.yaml` from `assets/algorithm.params.example.yaml`. Its
+`params.base` configuration must declare `epochs`, `batch_size`, and
+`input_size`. Recommend at least one `params.train` custom group using only
+values the generated training code actually reads, normally including `lr`
+and `optimizer`. Adjust ranges and defaults to the real algorithm instead of
+copying the example mechanically.
+
+Pass the file explicitly during upload with
+`--params-file algorithm.params.yaml`. The CLI does not auto-discover parameter
+metadata in the ZIP or working directory. A user-supplied algorithm may still
+be uploaded without a parameter file; explain that its corresponding training
+controls will not be declared until parameter metadata is added.
+
+Before uploading or rebuilding an algorithm, **MUST also read**
+`references/cli-commands.md` and use the documented `omni algorithm upload`
+arguments. Run `omni algorithm upload --help` if the installed CLI may differ
+from the bundled reference. Use `omni algorithm base-images --output json` to
+inspect the platform-supported images. Never guess an algorithm ID or base
+image value. When `--base-image` is omitted, the CLI uses the single image
+marked as the platform default.
+
+After local verification succeeds, use `omni algorithm upload`. The command
+validates the ZIP archive locally, creates the algorithm when `--algorithm-id`
+is not supplied, uploads the archive, and submits the platform build workflow.
+The archive must have one top-level directory containing
+`dataset_preprocess.py`, `train.py`, `val.py`, `dataset_postprocess.py`,
+`convert_onnx.py`, and `requirements.txt` directly under that directory.
+Retain the returned algorithm and build IDs. Diagnose the build with
+`omni algorithm build-status <algorithm_id> <build_id>` and
+`omni algorithm build-logs <algorithm_id> <build_id>`. Use
+`omni algorithm builds <algorithm_id>` when the build ID must be discovered.
+
+Never print or request an API Key in chat, call arbitrary REST URLs, access Django models, or parse human-readable CLI output.

omni_cli/bundled_skills/omni-train/assets/algorithm.params.example.yaml

@@ -0,0 +1,60 @@
+# Parameter metadata uploaded with:
+# omni algorithm upload ... --params-file algorithm.params.yaml
+# Adjust ranges and defaults to match the algorithm implementation.
+
+base:
+  epochs:
+    key: epochs
+    name: Epochs
+    choice_type: range
+    choice_value: [1, 200]
+    value_type: int
+    default: 100
+    step: 1
+    tips: Number of completed training epochs.
+
+  batch_size:
+    key: batch_size
+    name: Batch size
+    choice_type: range
+    choice_value: [1, 512]
+    value_type: int
+    default: 16
+    step: 1
+    tips: Number of samples processed in one training batch.
+
+  input_size:
+    key: input_size
+    name: Input size
+    choice_type: s_range
+    choice_value: [32, 2048]
+    value_type: int
+    default: [224, 224]
+    step: 1
+    tips: Model input size in [width, height] order.
+
+train:
+  learning-rate:
+    key: lr
+    name: Learning rate
+    choice_type: range
+    choice_value: [0.000001, 1.0]
+    value_type: float
+    default: 0.001
+    step: 0.000001
+    tips: Initial optimizer learning rate.
+
+  optimizer:
+    key: optimizer
+    name: Optimizer
+    choice_type: choice
+    choice_value:
+      - label: SGD
+        value: SGD
+      - label: Adam
+        value: Adam
+      - label: AdamW
+        value: AdamW
+    value_type: string
+    default: AdamW
+    tips: Optimizer used by the train stage.

omni_cli/bundled_skills/omni-train/assets/deploy.example.yaml

@@ -0,0 +1,18 @@
+schema_version: 1
+name: resnet18-qcs6490-int16
+model_id: 53
+format: ONNX
+chip: QCS6490/QCM6490
+system: Android
+framework: Qualcomm
+quantized: true
+configuration:
+  weight_type: int16
+  use_weight_per_channel: true
+  inputs:
+    - name: input
+      type: image
+      data_size: [224, 224]
+      mean: [0.485, 0.456, 0.406]
+      std: [0.229, 0.224, 0.225]
+      built_in_dataset: coco

omni_cli/bundled_skills/omni-train/assets/train.example.yaml

@@ -0,0 +1,31 @@
+schema_version: 1
+project:
+  name: vehicle-detection
+  type: image
+run:
+  name: baseline
+  type: detection
+  algorithm_id: 18
+dataset:
+  dataset_id: [25, 30]
+  label: [cat, dog]
+  splits:
+    - task_id: 69
+      mode: independent
+      train: 1
+      val: 0
+    - task_id: 68
+      mode: independent
+      train: 0
+      val: 1
+configuration:
+  # Optional overrides. Omit them to use the selected algorithm's defaults.
+  # epochs: 1
+  # batch_size: 1
+  # input_size: [224, 224]
+  # Use only stages and keys declared by `omni algorithm get 18`.
+  # Omitted declared values are filled from that algorithm's defaults on submit.
+  advanced_conf:
+    train:
+      lr: 0.1786
+      optimizer: SGD

omni_cli/bundled_skills/omni-train/references/cli-commands.md

@@ -0,0 +1,145 @@
+# CLI commands
+
+```text
+omni context show --output json
+# Keep the account default unless the user explicitly requests a switch
+omni workspace list --output json
+omni workspace use <workspace_id> --output json
+omni workspace reset --output json
+omni dataset list --output json
+omni dataset list --page 2 --page-size 50 --output json
+omni dataset list --all --output json
+omni dataset get <id> --output json
+omni dataset create --name demo-dataset --type classification --labels cat,dog --output json
+omni dataset upload ./dataset.zip --dataset-id <dataset_id> --subset-name train --output json
+omni dataset upload ./dataset.zip --dataset-id <dataset_id> --subset-name train --wait --timeout 1800 --output json
+# LabelMe: image and .json use the same directory and filename stem
+omni dataset upload ./labelme.zip --dataset-id <dataset_id> --subset-name train --labeled-format json --output json
+# Classification: images are grouped by an existing label directory
+omni dataset upload ./classification.zip --dataset-id <dataset_id> --subset-name train --labeled-format folder --output json
+omni task list --page-size 50 --output json
+omni task list --all --output json
+omni task get <id> --output json
+omni algorithm list --available --output json
+omni algorithm base-images --output json
+omni algorithm upload --name demo-classifier --type classification --archive ./algorithm.zip --output json
+omni algorithm upload --algorithm-id <id> --archive ./algorithm.zip --base-image open_platform:torch_2.7.1_cu118 --output json
+omni algorithm update <algorithm_id> --file algorithm-update.yaml --output json
+omni algorithm builds <algorithm_id> --all --output json
+omni algorithm build-status <algorithm_id> <build_id> --output json
+omni algorithm build-logs <algorithm_id> <build_id> --offset 0 --limit 200 --output json
+omni train list --page-size 50 --output json
+omni project list --all --output json
+omni project get <project_id> --output json
+omni project update <project_id> --file project-update.yaml --output json
+omni resource show --output json
+omni train validate --file train.yaml --output json
+# Recommended two-step flow
+omni train create --file train.yaml --output json
+omni train update <run_id> --file train.yaml --output json
+omni train submit --run-id <run_id> --output json
+# Backward-compatible create-and-start shortcut
+omni train submit --file train.yaml --output json
+omni train status <run_id> --output json
+# Detailed algorithm output from client.log (default)
+omni train logs <run_id> --log-type client --output json
+# Workflow-stage messages from task.log
+omni train logs <run_id> --log-type task --output json
+# Snapshot of both streams
+omni train logs <run_id> --log-type all --output json
+# Follow one stream without skipping offsets
+omni train logs <run_id> --log-type client --follow --output json
+omni train wait <run_id> --output json
+omni train stop <run_id> --output json
+omni train result <run_id> --output json
+omni train download <run_id> --output-path ./artifacts/model.zip --output json
+omni deploy platforms --output json
+omni deploy list --all --output json
+omni deploy get <deploy_id> --output json
+# Create only
+omni deploy create --file deploy.yaml --output json
+omni deploy update <deploy_id> --file deploy.yaml --output json
+# Create and start
+omni deploy submit --file deploy.yaml --output json
+# Start an existing deployment
+omni deploy submit --deploy-id <deploy_id> --output json
+omni deploy status <deploy_id> --output json
+omni deploy logs <deploy_id> --offset 0 --limit 200 --output json
+omni deploy wait <deploy_id> --output json
+omni deploy stop <deploy_id> --output json
+omni deploy download <deploy_id> --output-path ./artifacts/deployed-model.zip --output json
+omni deploy sdk <deploy_id> --output-path ./artifacts/omni-sdk.zip --output json
+omni deploy delete <deploy_id> --output json
+```
+
+`--labeled-format` automatically sends `is_labeled=true`. `json` performs a
+lightweight same-stem image/JSON check before upload. `folder` requires a
+classification dataset with tag annotations and existing labels; each image
+must be under its matching label directory, optionally below one common
+wrapper directory. The CLI does not infer labeled mode from ZIP contents.
+
+Upload completion only confirms file transfer. Labeled data import continues
+in the asynchronous dataset parsing task.
+
+Dataset creation and ZIP upload use the `dataset` API Key scope. Always take
+`dataset_id` from the create response; never infer it from a name. Dataset ZIP
+files are attached to a newly created subset task. Upload sessions are persisted
+locally and resumed from the server's TUS offset when the same command is run
+again. Keep resume enabled by default. `--restart` creates a new subset task and
+does not delete the previous task. Upload completion confirms file transfer only;
+parsing can still be `waiting` or `running`. Add `--wait` only when parsing
+completion is required.
+
+For a new algorithm, `--name`, `--type`, and `--archive` are required.
+`--description`, `--params-file`, and `--base-image` are optional. Skill-generated
+image algorithms should copy `assets/algorithm.params.example.yaml` to
+`algorithm.params.yaml` and pass it explicitly with
+`--params-file algorithm.params.yaml`; the CLI never searches the ZIP for it.
+
+For an existing algorithm, use `--algorithm-id`. If `--params-file` is
+provided, the CLI first calls `PATCH /api/algorithms/{id}` with the new `params`
+and uploads the archive only after that succeeds. Without `--params-file`, it
+keeps the existing parameters and uploads only the new source archive.
+`--name`, `--type`, and `--description` remain ignored for existing algorithms.
+
+The CLI always reads `baseImageOptions` from `GET /api/servers/options`.
+An explicit `--base-image` must match one of those values. When it is omitted,
+the CLI uses the single option marked with `default: true`; it never assumes
+the first option is the default.
+
+Example base image values from one platform release:
+
+```text
+open_platform:only_cuda_12.2.2
+open_platform:torch_2.7.1_cu118
+open_platform:torch_2.6.0_cu118
+open_platform:torch_2.5.1_cu121
+open_platform:torch_2.3.1_cu121
+open_platform:torch_2.1.1_cu121
+open_platform:torch_1.13.1_cu116
+```
+
+Always use the values returned by `omni algorithm base-images` rather than
+copying a value from an older Skill release.
+
+Deployment commands use the `deploy` API Key scope. `deploy create` never
+starts the workflow. `deploy submit --file` creates and starts it, while
+`deploy submit --deploy-id` starts an existing deployment. Keep stop and
+delete as separate, explicit actions.
+
+Update commands never change lifecycle state. Algorithm and project updates
+accept only their documented metadata fields. Training and deployment updates
+are accepted only while the record is `new`; their YAML files reuse the same
+create contracts, and nested configuration sections are complete replacements.
+
+REST mapping: algorithm, project, and training updates use standard
+`PATCH /api/algorithms/{id}`, `PATCH /api/trains/{id}`, and
+`PATCH /api/models/{id}`. Only deployment uses the dedicated
+`PATCH /api/deploys/{id}/config` endpoint.
+
+`omni train logs` accepts `--offset` and `--limit` for explicit paging. Its
+default log type is `client`, which exposes algorithm stdout and per-epoch
+training details stored in `client.log`. `task` reads the shorter workflow
+stage log, while `all` returns separate `task` and `client` snapshots and
+cannot be combined with `--follow`. With JSON output, `--follow` emits one JSON envelope per page
+so callers can process the stream line by line.