dataeval-flow 0.2.1__tar.gz → 0.2.3__tar.gz

{dataeval_flow-0.2.1 → dataeval_flow-0.2.3}/.gitignore

@@ -1,5 +1,6 @@
 # Environment
 .env
+.env.local
 .venv/
 __pycache__/
 *.pyc

{dataeval_flow-0.2.1 → dataeval_flow-0.2.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: dataeval-flow
-Version: 0.2.1
+Version: 0.2.3
 Summary: DataEval Workflows container for data evaluation
 Project-URL: Homepage, https://github.com/aria-ml/dataeval-flow
 Project-URL: Documentation, https://dataeval-flow.readthedocs.io/
@@ -19,7 +19,7 @@ Classifier: Topic :: Scientific/Engineering
 Classifier: Typing :: Typed
 Requires-Python: <3.15,>=3.10
 Requires-Dist: click>=8.0
-Requires-Dist: dataeval==1.1.0-rc6
+Requires-Dist: dataeval>=1.1.1
 Requires-Dist: datamaite[ic,od]==0.4.1
 Requires-Dist: numpy>=1.24.2
 Requires-Dist: pydantic>=2.0
@@ -49,11 +49,9 @@ Requires-Dist: onnx>=1.15; extra == 'onnx-cu130'
 Requires-Dist: onnxruntime-gpu>=1.27; (python_version >= '3.11' and extra != 'onnx-cu126') and extra == 'onnx-cu130'
 Requires-Dist: onnxruntime>=1.20; (python_version == '3.10' and extra != 'onnx-cu126') and extra == 'onnx-cu130'
 Provides-Extra: ontology
-Requires-Dist: dataeval[ontology]==1.1.0-rc6; extra == 'ontology'
+Requires-Dist: dataeval[ontology]>=1.1.1; extra == 'ontology'
 Provides-Extra: opencv
-Requires-Dist: opencv-python-headless>=4.8.0; extra == 'opencv'
-Provides-Extra: opencv-fips
-Requires-Dist: opencv-python-headless<4.13.0,>=4.8.0; extra == 'opencv-fips'
+Requires-Dist: opencv-python-headless<4.13.0,>=4.8.0; extra == 'opencv'
 Description-Content-Type: text/markdown
 
 <!-- markdownlint-disable MD041 -->
@@ -192,7 +190,7 @@ docker pull harbor.jatic.net/aria/dataeval:cu126   # cpu / cu126 / cu130
 **Pinned release channel** — immutable, version-tagged images cut from `v*` git tags. Use these for reproducible workloads.
 
 ```bash
-docker pull harbor.jatic.net/aria/dataeval:0.1.0-cu126
+docker pull harbor.jatic.net/aria/dataeval:0.2.1-cu126
 ```
 
 **Verifying the signature** — every published image is signed with
@@ -215,17 +213,23 @@ commands above with the fully-qualified `harbor.jatic.net/aria/dataeval:cu126`
 
 ## Requirements
 
-| Requirement   | Version               |
-| ------------- | --------------------- |
-| Docker        | >= 20.10              |
-| NVIDIA GPU    | Any (for GPU mode)    |
-| NVIDIA Driver | >= 520 (for GPU mode) |
-| CUDA          | 11.8.0 (for GPU mode) |
+| Requirement   | Version                                                        |
+| ------------- | -------------------------------------------------------------- |
+| Docker        | >= 20.10                                                       |
+| NVIDIA GPU    | Any (for GPU mode)                                             |
+| NVIDIA Driver | >= 525 for the `cu126` image; >= 580 for `cu130` (GPU mode)    |
+| CUDA          | 12.6 (`cu126`) or 13.0 (`cu130`) — bundled in the image        |
+
+The CUDA runtime libraries ship inside the image via PyTorch and `onnxruntime-gpu`, so
+the host needs only the NVIDIA driver and the NVIDIA Container Toolkit — no host CUDA
+install. The driver floors above are the CUDA major versions' minimums: any driver from
+the 525 series up runs a CUDA 12.x image under minor-version compatibility, and CUDA 13.0
+requires a 580-series or newer driver.
 
 ### Verify GPU Access
 
 ```bash
-docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi
+docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi
 ```
 
 ## Volume Mounts
@@ -289,7 +293,10 @@ precedence over them (see [Input Precedence](#input-precedence) below).
 
 No secret mounts or credentials are required — DataEval Flow uses no API keys,
 tokens, or passwords. (`DATAEVAL_FLOW_VERSION` and `DATAEVAL_NOX_UV_EXTRAS_OVERRIDE`
-are build-time only and are not read at run time.)
+are build-time only and are not read at run time. `UV_EXTRAS_OVERRIDE` and
+`CONTAINER_MODE` are baked into the image by the build and read at run time by the
+entrypoint, purely to label the help text and decide whether to run the GPU check —
+neither is meant to be set by the caller.)
 
 ## Input Precedence
 
@@ -344,12 +351,20 @@ Dataset and model paths in config files are resolved relative to the data root (
 
 ## Dataset Formats
 
-Currently supported dataset structures:
+A `datasets` entry selects its loader with `format`:
+
+| `format`       | Structure                                                     | Split selection                     |
+| -------------- | ------------------------------------------------------------- | ----------------------------------- |
+| `huggingface`  | HuggingFace arrow dataset or dataset dict                     | `split:` (omit for a single split)  |
+| `image_folder` | Directory of images, optionally one subdirectory per class    | n/a                                 |
+| `coco`         | COCO images plus a JSON annotation file                       | `annotations_file:` + `images_dir:` |
+| `yolo`         | Ultralytics root — `data.yaml` plus image/label trees         | `split:` (omit to load every split) |
 
-| Format          | Structure                                          | Example         |
-| --------------- | -------------------------------------------------- | --------------- |
-| **Dataset**     | Single split, used directly                        | `cifar10_test/` |
-| **DatasetDict** | Multiple splits (dict), configured via config YAML | `cifar10_full/` |
+Both single-split datasets and multi-split dataset dicts are supported. In-memory MAITE
+and TorchVision datasets are also accepted programmatically via `DatasetProtocolConfig`,
+which is not serializable and so cannot be named in a config file. See the
+[Run workflows in containers](https://dataeval-flow.readthedocs.io/en/latest/how_to/containerized_workflows.html)
+guide for the full field list of each format.
 
 ## CPU Fallback
 
@@ -366,13 +381,53 @@ docker run \
 
 ## CLI Modes
 
-DataEval Flow has three modes:
+DataEval Flow has four modes:
+
+| Command                   | Purpose                                                             |
+| ------------------------- | ------------------------------------------------------------------- |
+| `dataeval-flow [opts]`    | Headless execution — for automation and CI/CD pipelines             |
+| `dataeval-flow app`       | Interactive TUI dashboard — configure, execute, and view results    |
+| `dataeval-flow config`    | Simple CLI config builder — create/edit configs without the TUI     |
+| `dataeval-flow encoding`  | Write the metadata encoding descriptor a result was computed under  |
+| `dataeval-flow workflows` | List the available workflow types, or print one's parameter schema  |
+
+`dataeval-flow --version` reports the installed build — useful for pinning down
+which image produced a result.
+
+### Headless execution
+
+```bash
+# Every enabled task in the config
+dataeval-flow --config params.yaml --data . --output ./results
+
+# One task by name, whether or not the config marks it enabled
+dataeval-flow --config params.yaml --task clean_my_data
+
+# Several, in the order given
+dataeval-flow --config params.yaml --task clean_my_data --task analyze_my_data
+
+# Stop the pipeline when a finding breaches its health threshold
+dataeval-flow --config params.yaml --output ./results --fail-on-warning
+```
+
+**Exit codes:** `0` when every task succeeded, `1` when any task failed. Health
+warnings are reported but are not fatal unless you pass `--fail-on-warning`, which
+turns them into an exit code of `1` as well. Every run's `result.json` carries a
+`health` block per task (`status`, `warnings`, `findings`) so a pipeline can gate
+on findings without parsing the text report.
+
+### Workflow Discovery (`workflows`)
 
-| Command                | Purpose                                                          |
-| ---------------------- | ---------------------------------------------------------------- |
-| `dataeval-flow [opts]` | Headless execution — for automation and CI/CD pipelines          |
-| `dataeval-flow app`    | Interactive TUI dashboard — configure, execute, and view results |
-| `dataeval-flow config` | Simple CLI config builder — create/edit configs without the TUI  |
+For images that ship without the TUI extra:
+
+```bash
+# What can this build run?
+dataeval-flow workflows
+dataeval-flow workflows --json
+
+# What does a given workflow type accept?
+dataeval-flow workflows data-cleaning
+```
 
 ### Interactive TUI (`app`)
 
@@ -408,12 +463,35 @@ python -m dataeval_flow config --config /path/to/params.yaml
 
 Configs can be saved as YAML or JSON.
 
+### Encoding Descriptor (`encoding`)
+
+Extract the metadata encoding descriptor from an archived `result.json` and write it
+where it can be reviewed and committed, so a later dataset is cut the same way:
+
+```bash
+python -m dataeval_flow encoding output/results/result.json -o policy/factor_bins.json
+python -m dataeval_flow encoding output/results/result.json --task clean_my_data
+```
+
+Reference the committed descriptor from a metadata policy's `encoding` field. A run with
+`-o` already writes `results/encoding.json` beside its results; this command recovers one
+from a result archived earlier. See
+[Configure metadata binning](https://dataeval-flow.readthedocs.io/en/latest/how_to/configure_metadata_binning.html).
+
 ## Dependencies
 
+Declared runtime dependencies:
+
 - `dataeval` - Core evaluation library
-- `datamaite` - MAITE protocol dataset loaders
-- `maite` - MAITE protocol library
+- `datamaite` - MAITE protocol dataset loaders (which brings in `maite` itself)
 - `pydantic` - Structural typing and schema validation
+- `click` - Interactive prompts for the simple CLI config builder
+- `pyyaml` - YAML config parsing
+- `numpy` - Array handling
+
+PyTorch arrives transitively through `dataeval`. Optional extras (`onnx`, `opencv`,
+`app`, `ontology`, and the CUDA variants) are listed under
+[Running Without Container](#running-without-container).
 
 ## Troubleshooting
 

{dataeval_flow-0.2.1 → dataeval_flow-0.2.3}/README.md

@@ -134,7 +134,7 @@ docker pull harbor.jatic.net/aria/dataeval:cu126   # cpu / cu126 / cu130
 **Pinned release channel** — immutable, version-tagged images cut from `v*` git tags. Use these for reproducible workloads.
 
 ```bash
-docker pull harbor.jatic.net/aria/dataeval:0.1.0-cu126
+docker pull harbor.jatic.net/aria/dataeval:0.2.1-cu126
 ```
 
 **Verifying the signature** — every published image is signed with
@@ -157,17 +157,23 @@ commands above with the fully-qualified `harbor.jatic.net/aria/dataeval:cu126`
 
 ## Requirements
 
-| Requirement   | Version               |
-| ------------- | --------------------- |
-| Docker        | >= 20.10              |
-| NVIDIA GPU    | Any (for GPU mode)    |
-| NVIDIA Driver | >= 520 (for GPU mode) |
-| CUDA          | 11.8.0 (for GPU mode) |
+| Requirement   | Version                                                        |
+| ------------- | -------------------------------------------------------------- |
+| Docker        | >= 20.10                                                       |
+| NVIDIA GPU    | Any (for GPU mode)                                             |
+| NVIDIA Driver | >= 525 for the `cu126` image; >= 580 for `cu130` (GPU mode)    |
+| CUDA          | 12.6 (`cu126`) or 13.0 (`cu130`) — bundled in the image        |
+
+The CUDA runtime libraries ship inside the image via PyTorch and `onnxruntime-gpu`, so
+the host needs only the NVIDIA driver and the NVIDIA Container Toolkit — no host CUDA
+install. The driver floors above are the CUDA major versions' minimums: any driver from
+the 525 series up runs a CUDA 12.x image under minor-version compatibility, and CUDA 13.0
+requires a 580-series or newer driver.
 
 ### Verify GPU Access
 
 ```bash
-docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi
+docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi
 ```
 
 ## Volume Mounts
@@ -231,7 +237,10 @@ precedence over them (see [Input Precedence](#input-precedence) below).
 
 No secret mounts or credentials are required — DataEval Flow uses no API keys,
 tokens, or passwords. (`DATAEVAL_FLOW_VERSION` and `DATAEVAL_NOX_UV_EXTRAS_OVERRIDE`
-are build-time only and are not read at run time.)
+are build-time only and are not read at run time. `UV_EXTRAS_OVERRIDE` and
+`CONTAINER_MODE` are baked into the image by the build and read at run time by the
+entrypoint, purely to label the help text and decide whether to run the GPU check —
+neither is meant to be set by the caller.)
 
 ## Input Precedence
 
@@ -286,12 +295,20 @@ Dataset and model paths in config files are resolved relative to the data root (
 
 ## Dataset Formats
 
-Currently supported dataset structures:
+A `datasets` entry selects its loader with `format`:
+
+| `format`       | Structure                                                     | Split selection                     |
+| -------------- | ------------------------------------------------------------- | ----------------------------------- |
+| `huggingface`  | HuggingFace arrow dataset or dataset dict                     | `split:` (omit for a single split)  |
+| `image_folder` | Directory of images, optionally one subdirectory per class    | n/a                                 |
+| `coco`         | COCO images plus a JSON annotation file                       | `annotations_file:` + `images_dir:` |
+| `yolo`         | Ultralytics root — `data.yaml` plus image/label trees         | `split:` (omit to load every split) |
 
-| Format          | Structure                                          | Example         |
-| --------------- | -------------------------------------------------- | --------------- |
-| **Dataset**     | Single split, used directly                        | `cifar10_test/` |
-| **DatasetDict** | Multiple splits (dict), configured via config YAML | `cifar10_full/` |
+Both single-split datasets and multi-split dataset dicts are supported. In-memory MAITE
+and TorchVision datasets are also accepted programmatically via `DatasetProtocolConfig`,
+which is not serializable and so cannot be named in a config file. See the
+[Run workflows in containers](https://dataeval-flow.readthedocs.io/en/latest/how_to/containerized_workflows.html)
+guide for the full field list of each format.
 
 ## CPU Fallback
 
@@ -308,13 +325,53 @@ docker run \
 
 ## CLI Modes
 
-DataEval Flow has three modes:
+DataEval Flow has four modes:
+
+| Command                   | Purpose                                                             |
+| ------------------------- | ------------------------------------------------------------------- |
+| `dataeval-flow [opts]`    | Headless execution — for automation and CI/CD pipelines             |
+| `dataeval-flow app`       | Interactive TUI dashboard — configure, execute, and view results    |
+| `dataeval-flow config`    | Simple CLI config builder — create/edit configs without the TUI     |
+| `dataeval-flow encoding`  | Write the metadata encoding descriptor a result was computed under  |
+| `dataeval-flow workflows` | List the available workflow types, or print one's parameter schema  |
+
+`dataeval-flow --version` reports the installed build — useful for pinning down
+which image produced a result.
+
+### Headless execution
+
+```bash
+# Every enabled task in the config
+dataeval-flow --config params.yaml --data . --output ./results
+
+# One task by name, whether or not the config marks it enabled
+dataeval-flow --config params.yaml --task clean_my_data
+
+# Several, in the order given
+dataeval-flow --config params.yaml --task clean_my_data --task analyze_my_data
+
+# Stop the pipeline when a finding breaches its health threshold
+dataeval-flow --config params.yaml --output ./results --fail-on-warning
+```
+
+**Exit codes:** `0` when every task succeeded, `1` when any task failed. Health
+warnings are reported but are not fatal unless you pass `--fail-on-warning`, which
+turns them into an exit code of `1` as well. Every run's `result.json` carries a
+`health` block per task (`status`, `warnings`, `findings`) so a pipeline can gate
+on findings without parsing the text report.
+
+### Workflow Discovery (`workflows`)
 
-| Command                | Purpose                                                          |
-| ---------------------- | ---------------------------------------------------------------- |
-| `dataeval-flow [opts]` | Headless execution — for automation and CI/CD pipelines          |
-| `dataeval-flow app`    | Interactive TUI dashboard — configure, execute, and view results |
-| `dataeval-flow config` | Simple CLI config builder — create/edit configs without the TUI  |
+For images that ship without the TUI extra:
+
+```bash
+# What can this build run?
+dataeval-flow workflows
+dataeval-flow workflows --json
+
+# What does a given workflow type accept?
+dataeval-flow workflows data-cleaning
+```
 
 ### Interactive TUI (`app`)
 
@@ -350,12 +407,35 @@ python -m dataeval_flow config --config /path/to/params.yaml
 
 Configs can be saved as YAML or JSON.
 
+### Encoding Descriptor (`encoding`)
+
+Extract the metadata encoding descriptor from an archived `result.json` and write it
+where it can be reviewed and committed, so a later dataset is cut the same way:
+
+```bash
+python -m dataeval_flow encoding output/results/result.json -o policy/factor_bins.json
+python -m dataeval_flow encoding output/results/result.json --task clean_my_data
+```
+
+Reference the committed descriptor from a metadata policy's `encoding` field. A run with
+`-o` already writes `results/encoding.json` beside its results; this command recovers one
+from a result archived earlier. See
+[Configure metadata binning](https://dataeval-flow.readthedocs.io/en/latest/how_to/configure_metadata_binning.html).
+
 ## Dependencies
 
+Declared runtime dependencies:
+
 - `dataeval` - Core evaluation library
-- `datamaite` - MAITE protocol dataset loaders
-- `maite` - MAITE protocol library
+- `datamaite` - MAITE protocol dataset loaders (which brings in `maite` itself)
 - `pydantic` - Structural typing and schema validation
+- `click` - Interactive prompts for the simple CLI config builder
+- `pyyaml` - YAML config parsing
+- `numpy` - Array handling
+
+PyTorch arrives transitively through `dataeval`. Optional extras (`onnx`, `opencv`,
+`app`, `ontology`, and the CUDA variants) are listed under
+[Running Without Container](#running-without-container).
 
 ## Troubleshooting
 

{dataeval_flow-0.2.1 → dataeval_flow-0.2.3}/pyproject.toml

@@ -19,7 +19,7 @@ classifiers = [
 ]
 dependencies = [
     "click>=8.0",
-    "dataeval==1.1.0-rc6",
+    "dataeval>=1.1.1",
     "datamaite[ic,od]==0.4.1",
     "numpy>=1.24.2",
     "pydantic>=2.0",
@@ -51,10 +51,9 @@ onnx-cu130 = [
   "onnxruntime>=1.20; python_version == '3.10' and extra != 'onnx-cu126'",  # CUDA 13.0 is not supported on Python 3.10
   "onnxruntime-gpu>=1.27; python_version >= '3.11' and extra != 'onnx-cu126'",
 ]
-opencv = ["opencv-python-headless>=4.8.0"]  
-opencv-fips = ["opencv-python-headless>=4.8.0,<4.13.0"]  # OpenCV 4.13 and higher are not FIPS compliant
+opencv = ["opencv-python-headless>=4.8.0,<4.13.0"]  # OpenCV 4.13 and higher are not FIPS compliant
 app = ["textual>=3.0"]
-ontology = ["dataeval[ontology]==1.1.0-rc6"]
+ontology = ["dataeval[ontology]>=1.1.1"]
 
 [project.urls]
 Homepage = "https://github.com/aria-ml/dataeval-flow"
@@ -167,10 +166,6 @@ conflicts = [
     { extra = "onnx" },
     { extra = "onnx-cu126" },
     { extra = "onnx-cu130" },
-  ],
-  [
-    { extra = "opencv" },
-    { extra = "opencv-fips" },
   ]
 ]
 
@@ -216,8 +211,6 @@ torch = { version = ">=2.2.0", source = "pytorch-cpu", optional = true }
 torchvision = { version = ">=0.17.0", source = "pytorch-cpu", optional = true }
 
 [tool.pyproject2conda.dependencies]
-# Conda follows PEP versioning which deviates from PyPI semver
-dataeval = { skip = true, packages = "dataeval==1.1.0rc6" }
 datamaite = { pip = true }
 
 # --- Build System ---
@@ -334,7 +327,7 @@ ignore = [
     "C416",
 ]
 fixable = ["ALL"]
-per-file-ignores = { "tests/*" = ["ANN", "S101", "D", "SLF001", "ARG002", "PT019"], "docs/*" = ["D", "E402", "E501", "S101"], "verification/*" = ["ANN", "S101", "D", "SLF001", "ARG001", "ARG002", "PT011", "PT019"] }
+per-file-ignores = { "tests/*" = ["ANN", "S101", "D", "SLF001", "ARG002", "PT019"], "docs/*" = ["D", "E402", "E501", "S101"], "verification/*" = ["ANN", "S101", "D", "SLF001", "ARG001", "ARG002", "PT011", "PT019"], "scripts/*" = ["C901", "D", "S"] }
 
 [tool.ruff.lint.pydocstyle]
 convention = "pep257"
@@ -349,5 +342,5 @@ indent-style = "space"
 # --- Codespell ---
 
 [tool.codespell]
-skip = "./*env*,./output,./htmlcov,./.nox,*.lock,./docs/source/notebooks/*,./docker/cosign.pub,./docker/Dockerfile.*,*.onnx"
+skip = "./*env*,./output,./specs,./htmlcov,./.nox,*.lock,./docs/source/notebooks/*,./docker/cosign.pub,./docker/Dockerfile.*,*.onnx"
 ignore-words-list = ["statics"]