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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: dataeval-flow
-Version: 0.2.1
+Version: 0.2.2
 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.0
 Requires-Dist: datamaite[ic,od]==0.4.1
 Requires-Dist: numpy>=1.24.2
 Requires-Dist: pydantic>=2.0
@@ -49,7 +49,7 @@ 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.0; extra == 'ontology'
 Provides-Extra: opencv
 Requires-Dist: opencv-python-headless>=4.8.0; extra == 'opencv'
 Provides-Extra: opencv-fips
@@ -192,7 +192,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 +215,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 +295,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 +353,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 +383,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 +465,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
 
@@ -469,7 +549,7 @@ pip install dataeval-flow
 `torchvision` is not installed by default — it is imported lazily and is only needed
 for preprocessing pipelines, the torchvision dataset adapter, and the TUI's transform
 discovery. Install it together with `torch` in step 1 so both come from the same index.
-Feature extras (`onnx`, `onnx-cu126`, `onnx-cu130`, `opencv`, `app`, `ontology`) work normally under
+Feature extras (`onnx`, `onnx-cu126`, `onnx-cu130`, `opencv`, `opencv-fips`, `app`, `ontology`) work normally under
 pip and are independent of the PyTorch variant:
 
 ```bash

{dataeval_flow-0.2.1 → dataeval_flow-0.2.2}/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
 
@@ -411,7 +491,7 @@ pip install dataeval-flow
 `torchvision` is not installed by default — it is imported lazily and is only needed
 for preprocessing pipelines, the torchvision dataset adapter, and the TUI's transform
 discovery. Install it together with `torch` in step 1 so both come from the same index.
-Feature extras (`onnx`, `onnx-cu126`, `onnx-cu130`, `opencv`, `app`, `ontology`) work normally under
+Feature extras (`onnx`, `onnx-cu126`, `onnx-cu130`, `opencv`, `opencv-fips`, `app`, `ontology`) work normally under
 pip and are independent of the PyTorch variant:
 
 ```bash

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

@@ -19,7 +19,7 @@ classifiers = [
 ]
 dependencies = [
     "click>=8.0",
-    "dataeval==1.1.0-rc6",
+    "dataeval>=1.1.0",
     "datamaite[ic,od]==0.4.1",
     "numpy>=1.24.2",
     "pydantic>=2.0",
@@ -54,7 +54,7 @@ onnx-cu130 = [
 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
 app = ["textual>=3.0"]
-ontology = ["dataeval[ontology]==1.1.0-rc6"]
+ontology = ["dataeval[ontology]==1.1.0"]
 
 [project.urls]
 Homepage = "https://github.com/aria-ml/dataeval-flow"
@@ -216,8 +216,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 ---

{dataeval_flow-0.2.1 → dataeval_flow-0.2.2}/src/dataeval_flow/__main__.py

@@ -13,11 +13,22 @@ _logger = logging.getLogger(__name__)
 
 def _build_parser() -> argparse.ArgumentParser:
     """Build the argument parser with subcommands."""
+    from dataeval_flow import __version__
+
     parser = argparse.ArgumentParser(
         prog="dataeval_flow",
         description="DataEval Flow - Data evaluation and monitoring pipelines",
     )
 
+    # Long form only: -v is --verbose, and a container asking which build it is running
+    # is a different question from how loudly it should report.
+    parser.add_argument(
+        "--version",
+        action="version",
+        version=f"dataeval-flow {__version__}",
+        help="Show the installed dataeval-flow version and exit.",
+    )
+
     # Headless execution flags (top-level, no subcommand needed)
     parser.add_argument(
         "-v",
@@ -60,9 +71,50 @@ def _build_parser() -> argparse.ArgumentParser:
         default=Path(_cache_default) if _cache_default else None,
         help="Directory for disk-backed computation cache (default: $DATAEVAL_CACHE or None).",
     )
+    parser.add_argument(
+        "-t",
+        "--task",
+        action="append",
+        default=None,
+        metavar="NAME",
+        help=(
+            "Run only this task, by name. Repeat to run several, in the order given. "
+            "Naming a task runs it whether or not the config marks it enabled. "
+            "Default: every enabled task."
+        ),
+    )
+    parser.add_argument(
+        "--fail-on-warning",
+        action="store_true",
+        help=(
+            "Exit non-zero when a task succeeds but reports findings that breached their "
+            "health thresholds. Off by default, so a warning stays a prompt to look."
+        ),
+    )
 
     subparsers = parser.add_subparsers(dest="command")
 
+    # --- workflows (discovery) ---
+    workflows_parser = subparsers.add_parser(
+        "workflows",
+        help="List available workflow types, or show one's parameter schema",
+        description=(
+            "List the workflow types this build provides. Naming one prints the JSON "
+            "Schema for its parameters — the fields a `workflows:` entry of that type accepts."
+        ),
+    )
+    workflows_parser.add_argument(
+        "name",
+        nargs="?",
+        default=None,
+        help="Workflow type to describe (e.g. data-cleaning). Omit to list them all.",
+    )
+    workflows_parser.add_argument(
+        "--json",
+        action="store_true",
+        help="Emit the listing as JSON rather than a table.",
+    )
+
     # --- app (interactive TUI) ---
     app_parser = subparsers.add_parser(
         "app",
@@ -134,6 +186,41 @@ def _build_parser() -> argparse.ArgumentParser:
     return parser
 
 
+def _list_workflows(name: str | None, *, as_json: bool) -> int:
+    """Print the available workflow types, or one workflow's parameter schema.
+
+    Discovery without a TUI: the container image ships no browser and no Python REPL
+    worth the name, so the question "what can this build run, and what does it take?"
+    needs an answer from the command line.
+    """
+    import json
+
+    from dataeval_flow.workflow import get_workflow, list_workflows
+
+    if name is not None:
+        try:
+            workflow = get_workflow(name)
+        except ValueError as e:
+            print(f"ERROR: {e}", file=sys.stderr)
+            return 1
+        schema = workflow.params_schema
+        if schema is None:
+            print(f"{workflow.name} takes no parameters.")
+            return 0
+        print(json.dumps(schema.model_json_schema(), indent=2))
+        return 0
+
+    entries = sorted(list_workflows(), key=lambda w: w["name"])
+    if as_json:
+        print(json.dumps(entries, indent=2))
+        return 0
+
+    width = max(len(w["name"]) for w in entries)
+    for entry in entries:
+        print(f"  {entry['name']:<{width}}  {entry['description']}")
+    return 0
+
+
 def parse_args() -> argparse.Namespace:
     """Parse CLI arguments."""
     parser = _build_parser()
@@ -172,6 +259,9 @@ def main() -> NoReturn:
         setup_logging(verbosity=max(args.verbose, 2))
         sys.exit(write_encoding(args.result, args.output, args.task))
 
+    if args.command == "workflows":
+        sys.exit(_list_workflows(args.name, as_json=args.json))
+
     if args.command == "config":
         from dataeval_flow._app.cli import run_cli_builder
 
@@ -187,7 +277,17 @@ def main() -> NoReturn:
     try:
         from dataeval_flow.runner import run
 
-        sys.exit(run(args.config, args.output, data_dir=args.data, verbosity=args.verbose, cache_dir=args.cache))
+        sys.exit(
+            run(
+                args.config,
+                args.output,
+                data_dir=args.data,
+                verbosity=args.verbose,
+                cache_dir=args.cache,
+                tasks=args.task,
+                fail_on_warning=args.fail_on_warning,
+            )
+        )
     except (FileNotFoundError, ValueError, ImportError) as e:
         _logger.error("%s", e)
         sys.exit(1)

{dataeval_flow-0.2.1 → dataeval_flow-0.2.2}/src/dataeval_flow/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.2.1'
-__version_tuple__ = version_tuple = (0, 2, 1)
+__version__ = version = '0.2.2'
+__version_tuple__ = version_tuple = (0, 2, 2)
 
 __commit_id__ = commit_id = None