Skip to contents

Reports the reproducibility metadata for one of the [lcda_data()] datasets. Three different questions are answered by three different fields, because conflating them is exactly how a "reproducible" dataset stops being one:

Usage

lcda_provenance(name)

Arguments

name

dataset name (without the `.rds` extension), as in [lcda_data()].

Value

a one-row data frame with columns `dataset`, `generated_by`, `generated_on`, `first_release`, `shipped_in`, and `sha256`; or `NULL` (invisibly) if the dataset is not installed.

Details

`generated_by`

the package version whose code actually produced the numbers. A historical fact, recorded in the file when it was generated and never rewritten afterwards.

`first_release`

the package version in whose release this file first shipped, read from the `MANIFEST.csv` shipped with the data.

`shipped_in`

the version of the copy you are actually running, i.e. `packageVersion("lcdaGRASP")`.

`generated_by` is usually *older* than `shipped_in`: the simulation generators are expensive (LFR, large real networks, an OpenAlex query) and are re-run only when the algorithms change, not on every version bump. A dataset is therefore identified by its **content**, not by a version string: `sha256` is looked up from the `SHA256SUMS` manifest shipped alongside the data. That manifest stores bare file names, so verify it from inside the data directory: `cd inst/extdata && shasum -a 256 -c SHA256SUMS`.

The package's own tests enforce that every shipped dataset is listed in both manifests, that its checksum matches, and that no dataset claims to have been generated by a version newer than the installed one.

See also

[lcda_data()]

Examples

lcda_provenance("repro_summary")
#>         dataset generated_by generated_on first_release shipped_in
#> 1 repro_summary        0.3.1   2026-05-31         0.3.1      0.3.2
#>                                                             sha256
#> 1 1c69543fc7808ea9cd9c4b410b4fb74d1f5d7ee2410a7c2ab1fd8695d5ee091a