data-annotations 2.4.0__tar.gz → 2.6.0__tar.gz

{data_annotations-2.4.0 → data_annotations-2.6.0}/PKG-INFO

@@ -1,7 +1,7 @@
 Metadata-Version: 2.4
 Name: data-annotations
-Version: 2.4.0
-Summary: Annotate generated data artifacts
+Version: 2.6.0
+Summary: Annotate data artifacts with provenance and descriptions
 Keywords: annotations,data,metadata,provenance,reproducibility
 Author: Rodrigo C.  G.  Pena
 Author-email: Rodrigo C.  G.  Pena <rodrigo.cerqueiragonzalezpena@unibas.ch>
@@ -102,16 +102,23 @@ Every annotation document includes provenance with:
 - The script path relative to the Git repo root when it can be determined
 - Git commit, branch, dirty state, canonical repository remote, exact tags, and
   `git describe` output when available
+- A source-code reference for recovery, derived from Git metadata when possible
+  or supplied explicitly for archives, individual files, and DOI/URI records
 - The current `SLURM_JOB_ID` when available
 - Structured snapshots for recorded local inputs, including file checksums,
   directory content digests, and upstream annotation sidecar references when
   present
 
+Local file hashing defaults to checksum policy `auto`: existing files are hashed
+only up to `10 * 1024**3` bytes (10 GiB). Larger files are still recorded, but
+their `sha256` or directory `content_digest` is left unset unless you provide a
+precomputed checksum yourself.
+
 You can also attach your own parameters, input file paths, and function names.
 Local filesystem paths in provenance are stored as absolute paths. URI-style inputs
 such as `s3://...` or `https://...` are preserved as provided.
-Git tags and `git_describe` are human-friendly hints only; `git_sha` remains the
-source of truth for reproducibility, matching, and source checkout.
+Git tags and `git_describe` are human-friendly hints only. For Git sources,
+`git_sha` and `source_code.revision` identify the recoverable code state.
 
 ## Quick Start
 
@@ -500,6 +507,75 @@ README.
 If you want the direct writer approach instead, use `write_file_manifest(...)` and
 `write_directory_manifest(...)` (see `examples/`).
 
+## Checksum Policy
+
+All provenance and annotation entry points that hash local files support the same
+policy controls:
+
+- `checksum_policy="auto"`: hash existing local files only when they are at or
+  below `max_checksum_bytes`. This is the default, and
+  `max_checksum_bytes` defaults to `10 * 1024**3` bytes (10 GiB).
+- `checksum_policy="always"`: hash existing local files regardless of size.
+- `checksum_policy="never"`: never hash local files automatically. Checksums are
+  recorded only when you supply them explicitly.
+
+When a checksum is skipped, JSON sidecars keep the same schema and simply store
+`sha256: null`. Directory `content_digest` is also left unset when any tracked
+member file lacks a checksum.
+
+You can change the policy from Python:
+
+```python
+from data_annotations.annotations import annotate_file
+from data_annotations.provenance import write_file_manifest
+
+write_file_manifest(
+    "outputs/summary.txt",
+    checksum_policy="always",
+)
+
+annotate_file(
+    "outputs/summary.txt",
+    title="Run Summary",
+    summary="Post-hoc summary.",
+    artifact_sha256="precomputed-sha256",
+    checksum_policy="never",
+)
+```
+
+You can also inject precomputed checksums directly:
+
+- File APIs: pass `artifact_sha256=...`.
+- File or directory APIs: pass `checksum_overrides={path: sha256}`. For
+  directory outputs, keys can be relative to the output directory or absolute
+  paths.
+- Decorators such as `record_file_manifest(...)`, `record_directory_manifest(...)`,
+  `record_file_annotation(...)`, and `record_directory_annotation(...)` accept the
+  same checksum-policy arguments.
+
+From the CLI, use `--checksum-policy`, `--max-checksum-bytes`, `--sha256`, and
+repeatable `--checksum PATH=SHA256`:
+
+```bash
+data-annotations annotate file path/to/summary.txt \
+  --title "Run Summary" \
+  --summary "Post-hoc summary." \
+  --kind report \
+  --checksum-policy never \
+  --sha256 0123456789abcdef...
+
+data-annotations annotate directory path/to/run-001 \
+  --title "Processing outputs" \
+  --summary "Directory-level outputs." \
+  --checksum-policy never \
+  --checksum processed.csv=0123456789abcdef...
+
+data-annotations provenance chain path/to/run-001 \
+  --checksum-policy always
+```
+
+For a complete runnable workflow, see `examples/checksum_policy.py`.
+
 ## Description Layer
 
 The `data_annotations.description` sub-package provides the structured description
@@ -537,8 +613,9 @@ per call.
 Use `artifact_matches_manifest(...)` to verify whether a detached artifact still
 matches an annotation document. Use `analyze_provenance_chain(...)` when you also
 want to verify recorded inputs and recursively follow upstream annotation
-sidecars. Use `checkout_manifest_source(...)` to recover the recorded code state
-from Git metadata.
+sidecars. Use `recover_manifest_source(...)` to recover the recorded source code
+from Git metadata, a recorded source archive, or a recorded source file.
+`checkout_manifest_source(...)` remains available as a compatibility alias.
 
 ```python
 from pathlib import Path
@@ -546,7 +623,7 @@ from pathlib import Path
 from data_annotations.provenance import (
     analyze_provenance_chain,
     artifact_matches_manifest,
-    checkout_manifest_source,
+    recover_manifest_source,
 )
 
 annotation_path = Path("outputs/participants.csv.annotation.json")
@@ -555,7 +632,7 @@ artifact_path = Path("downloads/participants.csv")
 if artifact_matches_manifest(artifact_path, annotation_path):
     chain = analyze_provenance_chain(artifact_path)
     print(chain.status)
-    recovered = checkout_manifest_source(annotation_path)
+    recovered = recover_manifest_source(annotation_path)
     print(recovered.checkout_path)
     print(recovered.script_path)
 ```
@@ -572,9 +649,9 @@ still attach provenance and description after the fact.
 
 Post-hoc descriptions can still be very useful, but the quality of post-hoc
 provenance depends on how exact the supplied answers are. In particular, fields
-such as the generating script, command, function, Git commit, repository path,
-Git tags, `git describe` output, inputs, and parameters are only as reliable as
-the information entered during annotation.
+such as the generating script, command, function, source-code URI, Git commit,
+repository path, Git tags, `git describe` output, inputs, and parameters are
+only as reliable as the information entered during annotation.
 
 ## CLI Workflow
 
@@ -625,27 +702,34 @@ target: path/to/participants.csv
 title: Participant Cohort
 summary: Participant-level cohort assignments.
 kind: dataset
+sha256: 0123456789abcdef...
 
 inputs:
-  - ${DATA_ROOT}/raw/participants.csv
+    - ${DATA_ROOT}/raw/participants.csv
 
 params:
-  split: validation
+    split: validation
 
 provenance:
-  command: bash scripts/build_participants.sh
-  script: scripts/build_participants.sh
-  git_sha: deadbeef
+    command: bash scripts/build_participants.sh
+    script: scripts/build_participants.sh
+    git_sha: deadbeef
+    source_code:
+        kind: archive
+        uri: https://doi.org/10.5281/zenodo.12345
+        download_uri: https://zenodo.org/records/12345/files/source.zip
+        path: scripts/build_participants.sh
+        sha256: 0000000000000000000000000000000000000000000000000000000000000000
 
 fields:
-  - name: participant_id
-    summary: Stable participant identifier.
-    data_type: string
-    required: true
-    nullable: false
+    - name: participant_id
+      summary: Stable participant identifier.
+      data_type: string
+      required: true
+      nullable: false
 
 primary_key:
-  - participant_id
+    - participant_id
 ```
 
 Directory answers use an explicit inventory. Paths in `artifacts`,
@@ -658,26 +742,29 @@ title: Processing outputs
 summary: Files produced by the shell processing workflow.
 
 provenance:
-  command: bash process_from_instrument.sh
-  script: process_from_instrument.sh
+    command: bash process_from_instrument.sh
+    script: process_from_instrument.sh
+
+checksums:
+    processed.csv: 0123456789abcdef...
 
 artifacts:
-  - path: processed.csv
-    kind: dataset
-    title: Processed instrument output
-    summary: Normalized output from the processing script.
+    - path: processed.csv
+      kind: dataset
+      title: Processed instrument output
+      summary: Normalized output from the processing script.
 
 artifact_groups:
-  - title: Diagnostic plots
-    kind: plot
-    selector: plots/*.png
-    paths:
-      - plots/qc-1.png
-      - plots/qc-2.png
+    - title: Diagnostic plots
+      kind: plot
+      selector: plots/*.png
+      paths:
+          - plots/qc-1.png
+          - plots/qc-2.png
 
 child_bundles:
-  - path: model
-    annotation_path: model/data-annotations.json
+    - path: model
+      annotation_path: model/data-annotations.json
 ```
 
 Answers files may also use schema-style aliases such as `subject.path`,
@@ -685,14 +772,24 @@ Answers files may also use schema-style aliases such as `subject.path`,
 `description.artifacts`, `description.artifact_groups`, `provenance.inputs`,
 and `provenance.params`.
 
+For source-code recovery, `provenance.source_code.kind` may be `git`, `archive`,
+`file`, or `uri`. Git sources use `uri` plus `revision`; archive and file
+sources use `uri` or `download_uri` plus an optional `sha256`; `path` points to
+the generating script inside the recovered source. DOI or landing-page-only
+references can be recorded with `kind: uri`, but they are not directly
+recoverable unless a direct archive or file `download_uri` is also recorded.
+
 When group selectors are provided, the CLI expands them to concrete member paths
 at annotation time. Grouped files are tracked in `subject.produced_files[]` but
 are skipped by the per-file prompt flow, so you do not have to answer the same
 questions for every matching file.
 
-For post-hoc provenance, use repeatable `--git-tag` and optional
-`--git-describe` when you know the original code state. These values are stored
-as human-readable hints; `--git-sha` remains the field used for recovery.
+For post-hoc provenance, use `--source-kind`, `--source-uri`,
+`--source-download-uri`, `--source-path`, `--source-revision`, and
+`--source-sha256` when the generating code is recoverable from a Git remote,
+source archive, source file, or reference URI. Use repeatable `--git-tag` and
+optional `--git-describe` when you know the original Git state; these values are
+stored as human-readable hints.
 
 For provenance inspection and source recovery:
 
@@ -703,8 +800,12 @@ data-annotations provenance chain path/to/artifact --full-paths
 data-annotations provenance checkout path/to/artifact
 ```
 
-Command `checkout` downloads the recorded Git remote and checks out the recorded
-commit. It prompts before downloading source code and defaults to No; use
+Command `checkout` recovers the recorded source code. For Git sources, it clones
+the recorded remote and checks out the recorded revision. For archive and file
+sources, it downloads or copies the recorded object, verifies `sha256` when
+present, and resolves the generating script path when recorded. Reference-only
+URI sources are preserved in the annotation but are not directly recoverable.
+The command prompts before downloading source code and defaults to No; use
 `--force` when running trusted provenance checkout non-interactively.
 
 Command `match` auto-discovers `*.annotation.json` for files and `data-annotations.json` for
@@ -742,6 +843,11 @@ resolving an older installed command. From a source checkout, use
 `uv run data-annotations provenance chain ...`, or reinstall the CLI from the
 updated source before using the bare `data-annotations` command.
 
+Both `match` and `chain` also accept `--checksum-policy` and
+`--max-checksum-bytes`. Use `--checksum-policy always` when you want full
+verification of large local files, and leave the default `auto` when you prefer
+to avoid long checksum passes on very large artifacts.
+
 ### Run With `uvx`
 
 ```bash
@@ -820,6 +926,8 @@ uv run data-annotations publish path/to/run-001 path/to/publish-bundle
 - `ProducedFile`
 - `ChildBundle`
 - `InputArtifact`
+- `SourceCodeKind`
+- `SourceCodeReference`
 - `BaseProvenance`
 - `FileManifest`
 - `DirectoryManifest`
@@ -837,6 +945,7 @@ uv run data-annotations publish path/to/run-001 path/to/publish-bundle
 - `analyze_provenance_chain(...)`
 - `provenance_chain_is_fresh(...)`
 - `artifact_matches_manifest(...)`
+- `recover_manifest_source(...)`
 - `checkout_manifest_source(...)`
 
 ### Publish Functions
@@ -860,6 +969,7 @@ uv run python examples/record_file_description.py
 uv run python examples/record_directory_description.py
 uv run python examples/annotate_file.py
 uv run python examples/annotate_directory.py
+uv run python examples/checksum_policy.py
 uv run python examples/annotate_file_answers_cli.py
 uv run python examples/write_file_manifest.py
 uv run python examples/write_directory_manifest.py
@@ -869,6 +979,7 @@ uv run python examples/provenance_chain.py
 uv run python examples/provenance_chain_cli.py
 uv run python examples/recover_provenance.py
 uv run python examples/recover_provenance_cli.py
+uv run python examples/recover_archive_source.py
 uv run python examples/publish_cli.py
 ```
 

{data_annotations-2.4.0 → data_annotations-2.6.0}/README.md

@@ -72,16 +72,23 @@ Every annotation document includes provenance with:
 - The script path relative to the Git repo root when it can be determined
 - Git commit, branch, dirty state, canonical repository remote, exact tags, and
   `git describe` output when available
+- A source-code reference for recovery, derived from Git metadata when possible
+  or supplied explicitly for archives, individual files, and DOI/URI records
 - The current `SLURM_JOB_ID` when available
 - Structured snapshots for recorded local inputs, including file checksums,
   directory content digests, and upstream annotation sidecar references when
   present
 
+Local file hashing defaults to checksum policy `auto`: existing files are hashed
+only up to `10 * 1024**3` bytes (10 GiB). Larger files are still recorded, but
+their `sha256` or directory `content_digest` is left unset unless you provide a
+precomputed checksum yourself.
+
 You can also attach your own parameters, input file paths, and function names.
 Local filesystem paths in provenance are stored as absolute paths. URI-style inputs
 such as `s3://...` or `https://...` are preserved as provided.
-Git tags and `git_describe` are human-friendly hints only; `git_sha` remains the
-source of truth for reproducibility, matching, and source checkout.
+Git tags and `git_describe` are human-friendly hints only. For Git sources,
+`git_sha` and `source_code.revision` identify the recoverable code state.
 
 ## Quick Start
 
@@ -470,6 +477,75 @@ README.
 If you want the direct writer approach instead, use `write_file_manifest(...)` and
 `write_directory_manifest(...)` (see `examples/`).
 
+## Checksum Policy
+
+All provenance and annotation entry points that hash local files support the same
+policy controls:
+
+- `checksum_policy="auto"`: hash existing local files only when they are at or
+  below `max_checksum_bytes`. This is the default, and
+  `max_checksum_bytes` defaults to `10 * 1024**3` bytes (10 GiB).
+- `checksum_policy="always"`: hash existing local files regardless of size.
+- `checksum_policy="never"`: never hash local files automatically. Checksums are
+  recorded only when you supply them explicitly.
+
+When a checksum is skipped, JSON sidecars keep the same schema and simply store
+`sha256: null`. Directory `content_digest` is also left unset when any tracked
+member file lacks a checksum.
+
+You can change the policy from Python:
+
+```python
+from data_annotations.annotations import annotate_file
+from data_annotations.provenance import write_file_manifest
+
+write_file_manifest(
+    "outputs/summary.txt",
+    checksum_policy="always",
+)
+
+annotate_file(
+    "outputs/summary.txt",
+    title="Run Summary",
+    summary="Post-hoc summary.",
+    artifact_sha256="precomputed-sha256",
+    checksum_policy="never",
+)
+```
+
+You can also inject precomputed checksums directly:
+
+- File APIs: pass `artifact_sha256=...`.
+- File or directory APIs: pass `checksum_overrides={path: sha256}`. For
+  directory outputs, keys can be relative to the output directory or absolute
+  paths.
+- Decorators such as `record_file_manifest(...)`, `record_directory_manifest(...)`,
+  `record_file_annotation(...)`, and `record_directory_annotation(...)` accept the
+  same checksum-policy arguments.
+
+From the CLI, use `--checksum-policy`, `--max-checksum-bytes`, `--sha256`, and
+repeatable `--checksum PATH=SHA256`:
+
+```bash
+data-annotations annotate file path/to/summary.txt \
+  --title "Run Summary" \
+  --summary "Post-hoc summary." \
+  --kind report \
+  --checksum-policy never \
+  --sha256 0123456789abcdef...
+
+data-annotations annotate directory path/to/run-001 \
+  --title "Processing outputs" \
+  --summary "Directory-level outputs." \
+  --checksum-policy never \
+  --checksum processed.csv=0123456789abcdef...
+
+data-annotations provenance chain path/to/run-001 \
+  --checksum-policy always
+```
+
+For a complete runnable workflow, see `examples/checksum_policy.py`.
+
 ## Description Layer
 
 The `data_annotations.description` sub-package provides the structured description
@@ -507,8 +583,9 @@ per call.
 Use `artifact_matches_manifest(...)` to verify whether a detached artifact still
 matches an annotation document. Use `analyze_provenance_chain(...)` when you also
 want to verify recorded inputs and recursively follow upstream annotation
-sidecars. Use `checkout_manifest_source(...)` to recover the recorded code state
-from Git metadata.
+sidecars. Use `recover_manifest_source(...)` to recover the recorded source code
+from Git metadata, a recorded source archive, or a recorded source file.
+`checkout_manifest_source(...)` remains available as a compatibility alias.
 
 ```python
 from pathlib import Path
@@ -516,7 +593,7 @@ from pathlib import Path
 from data_annotations.provenance import (
     analyze_provenance_chain,
     artifact_matches_manifest,
-    checkout_manifest_source,
+    recover_manifest_source,
 )
 
 annotation_path = Path("outputs/participants.csv.annotation.json")
@@ -525,7 +602,7 @@ artifact_path = Path("downloads/participants.csv")
 if artifact_matches_manifest(artifact_path, annotation_path):
     chain = analyze_provenance_chain(artifact_path)
     print(chain.status)
-    recovered = checkout_manifest_source(annotation_path)
+    recovered = recover_manifest_source(annotation_path)
     print(recovered.checkout_path)
     print(recovered.script_path)
 ```
@@ -542,9 +619,9 @@ still attach provenance and description after the fact.
 
 Post-hoc descriptions can still be very useful, but the quality of post-hoc
 provenance depends on how exact the supplied answers are. In particular, fields
-such as the generating script, command, function, Git commit, repository path,
-Git tags, `git describe` output, inputs, and parameters are only as reliable as
-the information entered during annotation.
+such as the generating script, command, function, source-code URI, Git commit,
+repository path, Git tags, `git describe` output, inputs, and parameters are
+only as reliable as the information entered during annotation.
 
 ## CLI Workflow
 
@@ -595,27 +672,34 @@ target: path/to/participants.csv
 title: Participant Cohort
 summary: Participant-level cohort assignments.
 kind: dataset
+sha256: 0123456789abcdef...
 
 inputs:
-  - ${DATA_ROOT}/raw/participants.csv
+    - ${DATA_ROOT}/raw/participants.csv
 
 params:
-  split: validation
+    split: validation
 
 provenance:
-  command: bash scripts/build_participants.sh
-  script: scripts/build_participants.sh
-  git_sha: deadbeef
+    command: bash scripts/build_participants.sh
+    script: scripts/build_participants.sh
+    git_sha: deadbeef
+    source_code:
+        kind: archive
+        uri: https://doi.org/10.5281/zenodo.12345
+        download_uri: https://zenodo.org/records/12345/files/source.zip
+        path: scripts/build_participants.sh
+        sha256: 0000000000000000000000000000000000000000000000000000000000000000
 
 fields:
-  - name: participant_id
-    summary: Stable participant identifier.
-    data_type: string
-    required: true
-    nullable: false
+    - name: participant_id
+      summary: Stable participant identifier.
+      data_type: string
+      required: true
+      nullable: false
 
 primary_key:
-  - participant_id
+    - participant_id
 ```
 
 Directory answers use an explicit inventory. Paths in `artifacts`,
@@ -628,26 +712,29 @@ title: Processing outputs
 summary: Files produced by the shell processing workflow.
 
 provenance:
-  command: bash process_from_instrument.sh
-  script: process_from_instrument.sh
+    command: bash process_from_instrument.sh
+    script: process_from_instrument.sh
+
+checksums:
+    processed.csv: 0123456789abcdef...
 
 artifacts:
-  - path: processed.csv
-    kind: dataset
-    title: Processed instrument output
-    summary: Normalized output from the processing script.
+    - path: processed.csv
+      kind: dataset
+      title: Processed instrument output
+      summary: Normalized output from the processing script.
 
 artifact_groups:
-  - title: Diagnostic plots
-    kind: plot
-    selector: plots/*.png
-    paths:
-      - plots/qc-1.png
-      - plots/qc-2.png
+    - title: Diagnostic plots
+      kind: plot
+      selector: plots/*.png
+      paths:
+          - plots/qc-1.png
+          - plots/qc-2.png
 
 child_bundles:
-  - path: model
-    annotation_path: model/data-annotations.json
+    - path: model
+      annotation_path: model/data-annotations.json
 ```
 
 Answers files may also use schema-style aliases such as `subject.path`,
@@ -655,14 +742,24 @@ Answers files may also use schema-style aliases such as `subject.path`,
 `description.artifacts`, `description.artifact_groups`, `provenance.inputs`,
 and `provenance.params`.
 
+For source-code recovery, `provenance.source_code.kind` may be `git`, `archive`,
+`file`, or `uri`. Git sources use `uri` plus `revision`; archive and file
+sources use `uri` or `download_uri` plus an optional `sha256`; `path` points to
+the generating script inside the recovered source. DOI or landing-page-only
+references can be recorded with `kind: uri`, but they are not directly
+recoverable unless a direct archive or file `download_uri` is also recorded.
+
 When group selectors are provided, the CLI expands them to concrete member paths
 at annotation time. Grouped files are tracked in `subject.produced_files[]` but
 are skipped by the per-file prompt flow, so you do not have to answer the same
 questions for every matching file.
 
-For post-hoc provenance, use repeatable `--git-tag` and optional
-`--git-describe` when you know the original code state. These values are stored
-as human-readable hints; `--git-sha` remains the field used for recovery.
+For post-hoc provenance, use `--source-kind`, `--source-uri`,
+`--source-download-uri`, `--source-path`, `--source-revision`, and
+`--source-sha256` when the generating code is recoverable from a Git remote,
+source archive, source file, or reference URI. Use repeatable `--git-tag` and
+optional `--git-describe` when you know the original Git state; these values are
+stored as human-readable hints.
 
 For provenance inspection and source recovery:
 
@@ -673,8 +770,12 @@ data-annotations provenance chain path/to/artifact --full-paths
 data-annotations provenance checkout path/to/artifact
 ```
 
-Command `checkout` downloads the recorded Git remote and checks out the recorded
-commit. It prompts before downloading source code and defaults to No; use
+Command `checkout` recovers the recorded source code. For Git sources, it clones
+the recorded remote and checks out the recorded revision. For archive and file
+sources, it downloads or copies the recorded object, verifies `sha256` when
+present, and resolves the generating script path when recorded. Reference-only
+URI sources are preserved in the annotation but are not directly recoverable.
+The command prompts before downloading source code and defaults to No; use
 `--force` when running trusted provenance checkout non-interactively.
 
 Command `match` auto-discovers `*.annotation.json` for files and `data-annotations.json` for
@@ -712,6 +813,11 @@ resolving an older installed command. From a source checkout, use
 `uv run data-annotations provenance chain ...`, or reinstall the CLI from the
 updated source before using the bare `data-annotations` command.
 
+Both `match` and `chain` also accept `--checksum-policy` and
+`--max-checksum-bytes`. Use `--checksum-policy always` when you want full
+verification of large local files, and leave the default `auto` when you prefer
+to avoid long checksum passes on very large artifacts.
+
 ### Run With `uvx`
 
 ```bash
@@ -790,6 +896,8 @@ uv run data-annotations publish path/to/run-001 path/to/publish-bundle
 - `ProducedFile`
 - `ChildBundle`
 - `InputArtifact`
+- `SourceCodeKind`
+- `SourceCodeReference`
 - `BaseProvenance`
 - `FileManifest`
 - `DirectoryManifest`
@@ -807,6 +915,7 @@ uv run data-annotations publish path/to/run-001 path/to/publish-bundle
 - `analyze_provenance_chain(...)`
 - `provenance_chain_is_fresh(...)`
 - `artifact_matches_manifest(...)`
+- `recover_manifest_source(...)`
 - `checkout_manifest_source(...)`
 
 ### Publish Functions
@@ -830,6 +939,7 @@ uv run python examples/record_file_description.py
 uv run python examples/record_directory_description.py
 uv run python examples/annotate_file.py
 uv run python examples/annotate_directory.py
+uv run python examples/checksum_policy.py
 uv run python examples/annotate_file_answers_cli.py
 uv run python examples/write_file_manifest.py
 uv run python examples/write_directory_manifest.py
@@ -839,6 +949,7 @@ uv run python examples/provenance_chain.py
 uv run python examples/provenance_chain_cli.py
 uv run python examples/recover_provenance.py
 uv run python examples/recover_provenance_cli.py
+uv run python examples/recover_archive_source.py
 uv run python examples/publish_cli.py
 ```
 

{data_annotations-2.4.0 → data_annotations-2.6.0}/pyproject.toml

@@ -1,7 +1,7 @@
 [project]
 name = "data-annotations"
-version = "2.4.0"
-description = "Annotate generated data artifacts"
+version = "2.6.0"
+description = "Annotate data artifacts with provenance and descriptions"
 readme = "README.md"
 authors = [
   { name = "Rodrigo C.  G.  Pena", email = "rodrigo.cerqueiragonzalezpena@unibas.ch" },