Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`darnit-reproducibility`: heuristic checks for execution and build reproducibility signals

Aperta
  • Qualcosa non va?
#416 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
docker, python, r, rust
Ambito
build-system, devtools, tooling

Direzione di ricerca

Start by reading the sieve pass shape and the existing RE-02.01 HermeticBuild check referenced in #227, then review #414 for extracted signals and #415 for layer/tightness applicability. Define the new controls in the darnit-reproducibility TOML and ensure each follows the required pass shape; done means execution- and build-layer signals are covered, missing signals warn rather than pass, and signals serialize into the ontology vocabulary in #393.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

module-reproducibility

Summary

New sieve controls under darnit-reproducibility that gate on the signals
the extraction module (#414) surfaces, at the (layer, tightness) target
declared per the taxonomy (#415).

Scope: signals to check

Execution layer (Layer 2: built tool + inputs -> outputs)
  • Environment lockfile presence and pinning strength: uv.lock,
    poetry.lock, Pipfile.lock, conda-lock.yml, environment.yml,
    renv.lock, Manifest.toml, frozen-form requirements.txt.
  • Random seed calls: numpy.random.seed, torch.manual_seed,
    random.seed, tensorflow.random.set_seed, R set.seed.
  • Determinism flags: torch.use_deterministic_algorithms(True),
    CUBLAS_WORKSPACE_CONFIG, PYTHONHASHSEED, TF op-level determinism.
  • Non-determinism smells: datetime.now() on critical paths, unpinned
    network fetches (wget / curl without checksum).
  • Workflow specs (declarative beats scripts for auditability): Nextflow,
    Snakemake, CWL, Makefile, papermill-executed notebooks.
  • Data lineage markers: DVC (*.dvc), MLflow tracking, W&B,
    hash-pinned Zenodo DOIs vs raw GitHub URLs.
  • Container env: Dockerfile FROM <image>@sha256:... (pinned digest) vs
    :latest.
  • Compute-env capture: repo2docker-compatible layout.
Build layer (Layer 1: source -> built tool)
  • SOURCE_DATE_EPOCH in build scripts.
  • Locked toolchain: rust-toolchain.toml, .tool-versions (asdf),
    pinned Python interpreter in lockfile.
  • Reproducible-flags: -Wl,--build-id=none, -ffile-prefix-map,
    timestamp stripping.
  • Container-build digest pinning (build stage).
  • Cross-check against existing RE-02.01 HermeticBuild (see #227).

Each check emits a signal the extraction module (#414) exposes, at a
specific (layer, tightness) applicability declared per #415.

Non-goals for v0

  • Remediation actions (auto-generate Dockerfile, insert seed calls,
    produce lockfile) -- separate follow-up.
  • LLM-based verification of non-heuristic-detectable practices -- later,
    if signals below prove insufficient.
  • Language-specific idiomatic seeding beyond Python / R (Julia, Rust, Go
    idioms in v1+).

Constitution alignment

  • III. TOML-First: all controls defined in darnit-reproducibility's
    TOML.
  • II. Conservative-by-Default: missing signal at declared tier ->
    WARN, never silent PASS.
  • V. Sieve Pipeline Integrity: each check follows the sieve pass
    shape (file_must_exist -> exec/regex -> llm_eval -> manual).

Related

  • #414 (extractor module).
  • #415 (layer + tightness taxonomy -- each control declares
    applicability).
  • #227 (RE-02.01 HermeticBuild) -- Layer 1 heuristic already lives
    here; this issue widens the check family.
  • #393 (ontology) -- signals should serialize into the ontology vocab.
Lingua principale
Python
Stelle
22
Fork
27
Merge medio
1g 19h
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di darnitdevorg/darnit

Tutte le issue di darnitdevorg/darnit

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.