algorithm-nexus 0.3.0__tar.gz → 1.1.0__tar.gz

algorithm_nexus-1.1.0/.agents/skills/add-benchmark-instance/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: add-benchmark-instance
+description: >
+  Step-by-step guidance for adding a new problem instance (benchmark instance)
+  to an existing logical benchmark in Algorithm Nexus. Creates instance.yaml
+  (and optional artifact files), validates the instance definition, and opens a
+  pull request. Use when the user wants to add a new problem instance, benchmark
+  instance, or concrete instance to Algorithm Nexus.
+---
+
+# Adding a Benchmark Instance to Algorithm Nexus
+
+## Prerequisites
+
+The following information is required before creating a benchmark instance:
+
+- **Target logical benchmark (`benchmark_id`)**: The snake-case identifier of the existing problem class
+  (e.g. `graph_coloring`, `portfolio_optimization`). The benchmark definition must already exist at
+  `benchmarks/<benchmark_id>/benchmark.yaml`.
+    > **Note**: If the target problem does not exist yet, use the skill in
+    > `.agents/skills/add-logical-benchmark` to add the logical benchmark first before proceeding.
+- `instance_id` (string, required): Unique identifier for this instance, e.g. `erdos_renyi_50_02` or
+  `100nodes_random3regular`. This becomes the folder name under
+  `benchmarks/<benchmark_id>/instances/<instance_id>/` and the `instanceIdentifier` field value.
+- `description` (string, optional/recommended): Human-readable description of this concrete instance.
+- `problem_property_values` (list of PropertyValue, required if `problemProperties` are defined in
+  `benchmark.yaml`): Concrete values corresponding to the problem properties defined in
+  `benchmarks/<benchmark_id>/benchmark.yaml`. Each entry specifies:
+    - `property.identifier`: The identifier matching a `problemProperty` from `benchmark.yaml`.
+    - `value`: The concrete value for this instance (e.g. integer, float, string).
+- `instance_artifacts` (list of InstanceArtifact, optional): If the instance provides pre-generated
+  input files (such as graphs, datasets, or mathematical models) that algorithms consume directly:
+    - `property.identifier`: Identifier for the artifact slot (e.g. `graph`, `model`, `market_data`).
+    - `artifactsLocation`: Subfolder name relative to the instance directory containing the files.
+
+If the user has not provided enough information, ask for the missing details before creating files.
+
+## Steps
+
+1. **Gather information & verify problem existence** — verify the logical benchmark exists and confirm
+   all instance property values and artifacts.
+2. **Create the instance definition** — write
+   `benchmarks/<benchmark_id>/instances/<instance_id>/instance.yaml` and create artifact files if applicable.
+3. **Validate** — run `uv run nexus validate logical-benchmarks` and resolve any errors.
+4. **Commit, push, and open a PR** — commit changes to a new branch and open a pull request.
+
+---
+
+## Step 1 — Gather Information & Verify Problem Existence
+
+1. Verify that the parent logical benchmark exists at `benchmarks/<benchmark_id>/benchmark.yaml`.
+   - If `benchmark.yaml` does not exist or the user has not specified a problem, stop and guide the
+     user to create the benchmark problem first using the skill in `.agents/skills/add-logical-benchmark`.
+2. Inspect `benchmarks/<benchmark_id>/benchmark.yaml` to retrieve the declared `problemProperties`.
+3. Check whether an instance with the same `instance_id` already exists under
+   `benchmarks/<benchmark_id>/instances/<instance_id>/`. If it already exists, stop and inform the user.
+4. Distinguish between problem properties and instance artifacts:
+   - **Problem property values** define the parameters of the problem (e.g. `num_vertices: 50`,
+     `edge_density: 0.2`) and must match properties declared in `benchmark.yaml`.
+   - **Instance artifacts** are concrete input files (e.g. `.dimacs`, `.mps`, `.json`, `.csv`) stored
+     in a subfolder and referenced in `instanceArtifacts`. Artifact identifiers do not need to be
+     listed in `problemProperties`.
+
+---
+
+## Step 2 — Create the Instance Definition
+
+Create the instance folder:
+
+```bash
+mkdir -p benchmarks/<benchmark_id>/instances/<instance_id>
+```
+
+Write `benchmarks/<benchmark_id>/instances/<instance_id>/instance.yaml` following the schema below,
+including the IBM copyright header:
+
+```yaml
+# Copyright IBM Corp. 2026
+# SPDX-License-Identifier: Apache-2.0
+
+instanceIdentifier: <instance_id>
+benchmarkIdentifier: <benchmark_id>
+description: >
+  <description>
+
+problemPropertyValues:
+  - property:
+      identifier: <property_id_1>
+    value: <value_1>
+  - property:
+      identifier: <property_id_2>
+    value: <value_2>
+
+# (Optional) Include instanceArtifacts if the instance ships with input files
+instanceArtifacts:
+  - property:
+      identifier: <artifact_property_name>
+    artifactsLocation: <artifacts_subfolder>
+```
+
+### Artifact Files (Optional)
+
+If the instance includes artifact files:
+
+1. Create the subfolder under the instance directory:
+
+   ```bash
+   mkdir -p benchmarks/<benchmark_id>/instances/<instance_id>/<artifacts_subfolder>
+   ```
+
+2. Place or generate the required artifact files in that subfolder.
+3. Ensure `artifactsLocation` in `instance.yaml` matches the exact name of the subfolder.
+
+---
+
+## Step 3 — Validate
+
+Run the validation command from the repository root:
+
+```bash
+uv run nexus validate logical-benchmarks
+```
+
+To validate only the specific benchmark and its instances:
+
+```bash
+uv run nexus validate logical-benchmarks --file benchmarks/<benchmark_id>
+```
+
+A successful validation prints `success` for the benchmark. If validation fails:
+
+1. Read the error messages carefully (e.g. unknown problem property identifier, schema validation
+   errors, missing `artifactsLocation` subfolder).
+2. Fix `instance.yaml` or artifact files.
+3. Re-run validation until all checks pass.
+
+Do not proceed to the PR step until validation succeeds without errors.
+
+---
+
+## Step 4 — Commit, Push, and Open a PR
+
+Create a feature branch, stage all instance files, commit, and push:
+
+```bash
+git checkout -b add-<instance_id>-instance
+git add benchmarks/<benchmark_id>/instances/<instance_id>
+git commit -s -m "feat(benchmark): Add <instance_id> instance to <benchmark_id>"
+git push origin add-<instance_id>-instance
+```
+
+Then open a pull request from the new branch to the Algorithm Nexus `main` branch.
+Use the `create_pr_workflow` if available to generate the PR description automatically.

algorithm_nexus-1.1.0/.agents/skills/add-logical-benchmark/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: add-logical-benchmark
+description: >
+  Step-by-step guidance for adding a new problem class (logical benchmark) to
+  Algorithm Nexus. Creates benchmark.yaml, validates it, and opens a pull
+  request. Use when the user wants to add a new benchmark problem, problem
+  class, or logical-benchmark to Algorithm Nexus.
+---
+
+# Adding a Logical Benchmark (Problem Class) to Algorithm Nexus
+
+## Prerequisites
+
+The following information is required before starting. If any required item is
+missing, ask the user before proceeding.
+
+- `benchmark_id` (string, required): Snake-case unique identifier for the
+  problem, e.g. `graph_coloring`. This becomes both the folder name and the
+  `benchmarkIdentifier` value.
+- `title` (string, optional): Short human-readable display name.
+- `description` (string, required): What the benchmark evaluates — algorithm
+  class, inputs, goal.
+- `problem_properties` (list, required): The properties that characterise the
+  *abstract* problem — complexity parameters, size dimensions, structural
+  settings. Each property needs an `identifier` and an optional human-readable
+  `description`. A `propertyDomain` is optional (see Step 2).
+- `metrics` (list, optional): Canonical output metric names that every
+  experiment binding will report under. Each metric has an `identifier` and an
+  optional `metadata.description` — use it to explain what the metric measures
+  and its unit, rather than leaving that detail to the README.
+- `ranking_metric` and `ranking_order` (`asc` or `desc`, optional): Which
+  metric drives the leaderboard and in which direction.
+- `owner` (string, optional): GitHub team or username, e.g. `@my-team`.
+
+If the user has not provided enough information to fill in all required fields,
+ask for it before creating any files.
+
+## Steps
+
+1. **Gather information** — confirm all required prerequisite information.
+2. **Create the problem definition** — write `benchmarks/<benchmark_id>/benchmark.yaml`.
+3. **Write the README** — write `benchmarks/<benchmark_id>/README.md`.
+4. **Validate** — run `uv run nexus validate logical-benchmarks` and fix any errors.
+5. **Commit, push, and open a PR** — commit all changes to a new branch and open a pull request.
+
+---
+
+## Step 1 — Gather Information
+
+Before writing any file, confirm all prerequisite information is available.
+Inspect the workspace to check whether a benchmark with the same identifier
+already exists under `benchmarks/`. If it does, stop and inform the user.
+
+### Distinguish problem properties from instance artifacts
+
+Before finalising `problemProperties`, review each proposed property with the
+following question:
+
+> **Does this property describe the abstract problem (its size, structure, or
+> parameters), or does it represent a pre-generated input file that an
+> algorithm will consume directly?**
+
+- **Scalar/categorical parameters** that characterise problem complexity (e.g.
+  number of nodes, graph family, budget, risk-aversion weight) → declare as
+  `problemProperties` in `benchmark.yaml`.
+- **Files or datasets** that are derived from those parameters and fed directly
+  to algorithms (e.g. a graph in DIMACS format, an MPS model file, a JSON
+  representation) → these are **instance artifacts**, not problem properties.
+  They belong in `instanceArtifacts` on the instance, not in `problemProperties`
+  on the benchmark. Do not add them to `problemProperties`.
+
+If the user describes a property that is clearly a file input, flag it and
+explain that it should be an instance artifact instead. Only proceed with
+writing `benchmark.yaml` once this distinction has been applied.
+
+---
+
+## Step 2 — Create the Problem Definition
+
+Create the benchmark folder and `benchmark.yaml`:
+
+```bash
+mkdir -p benchmarks/<benchmark_id>
+```
+
+Write `benchmarks/<benchmark_id>/benchmark.yaml` with the following structure,
+including the IBM copyright header:
+
+```yaml
+# Copyright IBM Corp. 2026
+# SPDX-License-Identifier: Apache-2.0
+
+benchmarkIdentifier: <benchmark_id>
+title: <title>
+description: >
+  <description>
+problemProperties:
+  - identifier: <property_id>
+    metadata:
+      description: <property description>
+    # propertyDomain is optional — omit it when the property is open-ended
+    propertyDomain:
+      variableType: <DOMAIN_TYPE>
+      values: [...]          # for CATEGORICAL_VARIABLE_TYPE or DISCRETE_VARIABLE_TYPE
+metrics:
+  - identifier: <metric_id>
+    metadata:
+      description: <what this metric measures and its unit>
+ranking:
+  metric: <metric_id>
+  order: asc   # or desc
+owner: "<owner>"
+```
+
+Only include `title`, `metrics`, `ranking`, and `owner` if the information is
+available. Only include `propertyDomain` when it adds meaningful constraint or
+documentation value; omit it for open-ended properties.
+
+**Property domain types** — choose the right `variableType` when a domain is
+declared:
+
+| User intent | `variableType` | Extra fields |
+| --- | --- | --- |
+| A fixed set of named categories | `CATEGORICAL_VARIABLE_TYPE` | `values: [a, b, c]` |
+| A fixed set of integer counts | `DISCRETE_VARIABLE_TYPE` | `values: [10, 50, 100]` |
+| Any real number | `CONTINUOUS_VARIABLE_TYPE` | *(none, or `domainRange: [lo, hi]`)* |
+| No constraint / open-ended | omit `propertyDomain` entirely | — |
+
+---
+
+## Step 3 — Write the README
+
+Create `benchmarks/<benchmark_id>/README.md` alongside `benchmark.yaml`. The
+README gives a human-readable problem statement that is not constrained by YAML
+syntax. It should cover:
+
+- **Problem formulation** — what is being optimised or evaluated, objective,
+  constraints.
+- **Instance structure** — what the problem properties represent and how they
+  combine to define a concrete instance.
+- **References** — papers, datasets, or external benchmark suites the problem
+  is drawn from (if any).
+
+Write the README from the information gathered in Step 1. If the user has not
+provided enough detail to write a meaningful formulation, ask before proceeding.
+
+---
+
+## Step 4 — Validate
+
+Run the validation command from the repository root:
+
+```bash
+uv run nexus validate logical-benchmarks
+```
+
+To validate only the new benchmark:
+
+```bash
+uv run nexus validate logical-benchmarks --file benchmarks/<benchmark_id>
+```
+
+A successful run prints `success` for the benchmark folder. If validation fails:
+
+1. Read the error messages carefully — they are usually Pydantic schema errors
+   or missing required fields.
+2. Fix `benchmark.yaml`.
+3. Re-run validation until all errors are resolved.
+
+Do not proceed to the PR step until validation passes with no errors.
+
+---
+
+## Step 5 — Commit, Push, and Open a PR
+
+Stage and commit everything:
+
+```bash
+git checkout -b add-<benchmark_id>-benchmark
+git add benchmarks/<benchmark_id>
+git commit -s -m "feat(benchmark): Add <benchmark_id> problem class"
+git push origin add-<benchmark_id>-benchmark
+```
+
+Then open a pull request from the new branch to the Algorithm Nexus main branch.
+Use the `create_pr_workflow` if available to generate the PR description
+automatically.

{algorithm_nexus-0.3.0 → algorithm_nexus-1.1.0}/.pre-commit-config.yaml

@@ -17,7 +17,7 @@ repos:
 
   # Ruff - Python linter and formatter
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.15.20
+    rev: v0.16.10
     hooks:
       - id: ruff
         args: [--fix]
@@ -35,7 +35,7 @@ repos:
 
   # Codespell - Check for common misspellings
   - repo: https://github.com/codespell-project/codespell
-    rev: v2.4.2
+    rev: v2.4.3
     hooks:
       - id: codespell
         additional_dependencies: ["tomli"]
@@ -43,7 +43,7 @@ repos:
 
   # UV lock check
   - repo: https://github.com/astral-sh/uv-pre-commit
-    rev: 0.11.26
+    rev: 0.12.23
     hooks:
       - id: uv-lock
       - id: uv-export
@@ -64,7 +64,7 @@ repos:
 
   # Markdownlint - Markdown linting
   - repo: https://github.com/DavidAnson/markdownlint-cli2
-    rev: v0.23.0
+    rev: v0.23.3
     hooks:
       - id: markdownlint-cli2
 
@@ -76,7 +76,7 @@ repos:
 
   # Tombi - TOML formatting
   - repo: https://github.com/tombi-toml/tombi-pre-commit
-    rev: v1.2.0
+    rev: v1.7.2
     hooks:
       - id: tombi-format
         args: ["--offline"]

{algorithm_nexus-0.3.0 → algorithm_nexus-1.1.0}/.secrets.baseline

@@ -1,9 +1,9 @@
 {
   "exclude": {
-    "files": "^.secrets$|^.secrets.baseline$",
+    "files": "^.secrets$|^.secrets.baseline$|^requirements-candidate.txt$|^requirements-ecosystem.txt$|^requirements-product.txt$",
     "lines": null
   },
-  "generated_at": "2026-08-18T13:37:11Z",
+  "generated_at": "2026-09-11T09:26:16Z",
   "plugins_used": [
     {
       "name": "AWSKeyDetector"
@@ -76,18 +76,7 @@
       "name": "TwilioKeyDetector"
     }
   ],
-  "results": {
-    "requirements-ecosystem.txt": [
-      {
-        "hashed_secret": "52b44e0998fd3bcb1929ac25818191fae050cf1d",
-        "is_secret": false,
-        "is_verified": false,
-        "line_number": 825,
-        "type": "Secret Keyword",
-        "verified_result": null
-      }
-    ]
-  },
+  "results": {},
   "version": "0.13.1+ibm.64.dss",
   "word_list": {
     "file": null,

{algorithm_nexus-0.3.0 → algorithm_nexus-1.1.0}/CHANGELOG.md

@@ -1,3 +1,35 @@
+## [1.0.0](https://github.com/ibm/algorithm-nexus/compare/f3f8054bba7a0ac14581b1d45e9c655cba984266..1.0.0) - 2026-09-29
+#### Documentation
+- (**benchmarks**) Improved benchmarks terminology and adapted schema accordingly (#250) - ([57fcfa7](https://github.com/ibm/algorithm-nexus/commit/57fcfa75960716c1adadadb5ad8ff819f839f385)) - Christian Pinto
+- (**changelog**) add release notes for 0.3.0 (#219) - ([f3f8054](https://github.com/ibm/algorithm-nexus/commit/f3f8054bba7a0ac14581b1d45e9c655cba984266)) - DRL-NextGen
+- (**experiments**) Refactored experiment and benchmarks folder structure (#259) - ([5482773](https://github.com/ibm/algorithm-nexus/commit/5482773886999e63f91f2c4b81b796c3e809596c)) - Christian Pinto
+- (**reqa**) Update benchmarking reqs (#261) - ([7c811f9](https://github.com/ibm/algorithm-nexus/commit/7c811f987aea21760cdcf8ec4fc99a6de54ae65c)) - Michael Johnston
+- benchmark how-tos (#273) - ([2ac3469](https://github.com/ibm/algorithm-nexus/commit/2ac34696396edc7baaf455d5f6acc6f17fd03da8)) - Michael Johnston
+- update benchmark design doc structure and harmonise terminology (#266) - ([9f251bd](https://github.com/ibm/algorithm-nexus/commit/9f251bd8c5460ffe23e75908c98bd2a77e8a48e3)) - Michael Johnston
+#### Build system
+- (**dependencies**) Updated vllm to v0.30.0 (#251) - ([cc4198f](https://github.com/ibm/algorithm-nexus/commit/cc4198f8eec52b0207cae128d1a1e80bbe87c949)) - Christian Pinto
+- (**deps**) update dependencies (#270) - ([12538be](https://github.com/ibm/algorithm-nexus/commit/12538be9eb933ba1ee66381e5fb9d8ef2ce26a0d)) - DRL-NextGen
+- (**deps**) update dependencies (#248) - ([cfef198](https://github.com/ibm/algorithm-nexus/commit/cfef1989e42b9ddb68ca6acb57991eb1368d866e)) - DRL-NextGen
+- (**deps**) update dependencies (#245) - ([8b72898](https://github.com/ibm/algorithm-nexus/commit/8b72898d5e14732971eb068537818b1af3112b32)) - DRL-NextGen
+- (**deps**) update dependencies (#239) - ([ff886d6](https://github.com/ibm/algorithm-nexus/commit/ff886d684711b62cc2a1beb6f90043cfb11dd966)) - DRL-NextGen
+- (**deps**) Updated vllm (0.29.) and terratorch (1.2.13) versions in candidate target (#238) - ([0a8c880](https://github.com/ibm/algorithm-nexus/commit/0a8c880cba0b1c96d8287e4d1eaf9a830561b44a)) - Christian Pinto
+- (**deps**) update dependencies (#234) - ([c7c30d1](https://github.com/ibm/algorithm-nexus/commit/c7c30d19d7e67b5e30bb73549cc33a7cccbca33b)) - DRL-NextGen
+- (**hooks**) update pre-commit hooks (#249) - ([55834b0](https://github.com/ibm/algorithm-nexus/commit/55834b0e516d2302d7dce30f6b7787de09fb1c64)) - DRL-NextGen
+- (**hooks**) update pre-commit hooks (#244) - ([fb1c11d](https://github.com/ibm/algorithm-nexus/commit/fb1c11d42940c4f99cce92fc999dd2a1df6054e2)) - DRL-NextGen
+- (**hooks**) update pre-commit hooks (#227) - ([c2cd126](https://github.com/ibm/algorithm-nexus/commit/c2cd12647aafa4579390ffb53efc661231893f88)) - DRL-NextGen
+#### Miscellaneous Chores
+- exclude autogenerated requirements file from detect-secrets (#233) - ([a337773](https://github.com/ibm/algorithm-nexus/commit/a33777333e749c047511922600aa0d008411f0a0)) - Alessandro Pomponio
+
+- - -
+
+## [0.3.0](https://github.com/ibm/algorithm-nexus/compare/f6eeb79b27485ed30089ec3b8e216d8756b1971a..0.3.0) - 2026-08-31
+#### Features
+- (**dependencies**) Updated vllm to 0.28.x and terratorch to 1.2.13 (#218) - ([7bdaea9](https://github.com/ibm/algorithm-nexus/commit/7bdaea9a97534de8376c1826c424b35e65b0bf1b)) - Christian Pinto
+#### Documentation
+- (**changelog**) add release notes for 0.2.3 (#215) - ([f6eeb79](https://github.com/ibm/algorithm-nexus/commit/f6eeb79b27485ed30089ec3b8e216d8756b1971a)) - DRL-NextGen
+
+- - -
+
 ## [0.2.3](https://github.com/ibm/algorithm-nexus/compare/36f3d99129ddf64de7f5098e4f1c290b991efa18..0.2.3) - 2026-08-25
 #### Features
 - (**dependencies**) Relaxed vllm dependency in product target (#214) - ([5926fdf](https://github.com/ibm/algorithm-nexus/commit/5926fdf6e38d8def91ab5ceed2a2b01b258d24c9)) - Christian Pinto

{algorithm_nexus-0.3.0 → algorithm_nexus-1.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: algorithm-nexus
-Version: 0.3.0
+Version: 1.1.0
 Summary: A comprehensive library for AI model delivery, testing, and benchmarking
 Project-URL: Homepage, https://github.com/IBM/algorithm-nexus
 Project-URL: Issues, https://github.com/IBM/algorithm-nexus/issues
@@ -10,12 +10,10 @@ Maintainer-email: Christian Pinto <christian.pinto@ibm.com>
 License-File: LICENSE
 Requires-Python: <3.14,>=3.12
 Provides-Extra: candidate
-Requires-Dist: biomed-multi-alignment[vllm]; extra == 'candidate'
 Requires-Dist: bmfm-targets[vllm]>=0.20.0; extra == 'candidate'
 Requires-Dist: opencv-python-headless!=5.0.0.93; extra == 'candidate'
-Requires-Dist: terrakit==0.2.0; extra == 'candidate'
-Requires-Dist: terratorch[vllm]==1.2.10; extra == 'candidate'
-Requires-Dist: vllm==0.26.0; extra == 'candidate'
+Requires-Dist: terratorch[vllm]==1.2.13; extra == 'candidate'
+Requires-Dist: vllm<0.32.0,>=0.31.0; extra == 'candidate'
 Provides-Extra: cli
 Requires-Dist: ado-core>=2.0; extra == 'cli'
 Requires-Dist: pydantic>=2.13.3; extra == 'cli'
@@ -23,7 +21,6 @@ Requires-Dist: pyyaml>=6.0.3; extra == 'cli'
 Requires-Dist: rich>=15.0.0; extra == 'cli'
 Requires-Dist: typer>=0.25.0; extra == 'cli'
 Provides-Extra: ecosystem
-Requires-Dist: biomed-multi-alignment; extra == 'ecosystem'
 Requires-Dist: bmfm-targets; extra == 'ecosystem'
 Requires-Dist: gridfm-graphkit==0.8.1; extra == 'ecosystem'
 Requires-Dist: terrakit>=0.2.0; extra == 'ecosystem'
@@ -31,9 +28,8 @@ Requires-Dist: terratorch>=1.2.7; extra == 'ecosystem'
 Requires-Dist: tokamind; extra == 'ecosystem'
 Provides-Extra: product
 Requires-Dist: opencv-python-headless!=5.0.0.93; extra == 'product'
-Requires-Dist: terrakit==0.2.0; extra == 'product'
 Requires-Dist: terratorch[vllm]==1.2.13; extra == 'product'
-Requires-Dist: vllm<0.29.0,>=0.28.0; extra == 'product'
+Requires-Dist: vllm<0.32.0,>=0.31.0; extra == 'product'
 Description-Content-Type: text/markdown
 
 # Algorithm Nexus
@@ -250,7 +246,7 @@ nexus list benchmark-packages ./packages --nexus-package terratorch
 #### List benchmark experiments
 
 ```bash
-nexus list benchmark-experiments [PACKAGES_ROOT]
+nexus list experiments [PACKAGES_ROOT]
 ```
 
 Lists all benchmark experiments with their associated benchmark packages and
@@ -259,22 +255,7 @@ Nexus packages. Filter by a specific Nexus package with `--nexus-package`.
 **Example:**
 
 ```bash
-nexus list benchmark-experiments ./packages -o json
-```
-
-#### Get benchmark requirements
-
-```bash
-nexus get benchmark-requirements NEXUS_PACKAGE [PACKAGES_ROOT]
-```
-
-Retrieves the benchmark requirement specifiers for a specific Nexus package.
-Output in requirements.txt format with `-o txt` for use with pip.
-
-**Example:**
-
-```bash
-nexus get benchmark-requirements terratorch ./packages -o txt --output-file requirements.txt
+nexus list experiments ./packages -o json
 ```
 
 ### Output formats
@@ -284,7 +265,6 @@ Most list commands support multiple output formats:
 - **Table** (default): Human-readable table output
 - **JSON** (`-o json`): Machine-readable JSON format
 - **CSV** (`-o csv`): Comma-separated values for spreadsheets
-- **TXT** (`-o txt`): Requirements file format (get commands only)
 
 Use `--output-file` to write output to a file instead of stdout.
 

{algorithm_nexus-0.3.0 → algorithm_nexus-1.1.0}/README.md

@@ -212,7 +212,7 @@ nexus list benchmark-packages ./packages --nexus-package terratorch
 #### List benchmark experiments
 
 ```bash
-nexus list benchmark-experiments [PACKAGES_ROOT]
+nexus list experiments [PACKAGES_ROOT]
 ```
 
 Lists all benchmark experiments with their associated benchmark packages and
@@ -221,22 +221,7 @@ Nexus packages. Filter by a specific Nexus package with `--nexus-package`.
 **Example:**
 
 ```bash
-nexus list benchmark-experiments ./packages -o json
-```
-
-#### Get benchmark requirements
-
-```bash
-nexus get benchmark-requirements NEXUS_PACKAGE [PACKAGES_ROOT]
-```
-
-Retrieves the benchmark requirement specifiers for a specific Nexus package.
-Output in requirements.txt format with `-o txt` for use with pip.
-
-**Example:**
-
-```bash
-nexus get benchmark-requirements terratorch ./packages -o txt --output-file requirements.txt
+nexus list experiments ./packages -o json
 ```
 
 ### Output formats
@@ -246,7 +231,6 @@ Most list commands support multiple output formats:
 - **Table** (default): Human-readable table output
 - **JSON** (`-o json`): Machine-readable JSON format
 - **CSV** (`-o csv`): Comma-separated values for spreadsheets
-- **TXT** (`-o txt`): Requirements file format (get commands only)
 
 Use `--output-file` to write output to a file instead of stdout.