Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

`darnit-reproducibility`: environment-generation sieve (deterministic-first, LLM fallback)

Abierto
  • ¿Algo no está bien?
#422 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
docker, python
Área
build-system, tooling

Línea de trabajo

Start by reading the control-sieve pattern and related issue #421, then inspect the repo2docker Python API (repo2docker.Repo2Docker). The issue asks for a design and prototype, not a named file or test: define the deterministic-to-LLM-to-manual pass behavior, evidence and artifact choices, and operator sign-off. Done means the deterministic reference integration and auditable design are documented without silently applying generated artifacts.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

module-reproducibility

Summary

darnit is positioned to help with the reproducibility edge cases --
the places where existing environment-generation tooling (repo2docker,
Cloud Native Buildpacks, devcontainer templates) doesn't reach. This
issue scopes a "sieve" for environment generation that mirrors
darnit's own control-sieve pattern: try deterministic tools first,
escalate to an LLM only where they can't conclude, always with
operator sign-off before applying.

This is not a plan to compete with repo2docker or buildpacks. It's a
plan to route to them first, then fill the gaps.

Prior art (deterministic tier)

  • repo2docker (Jupyter/Binder): detects requirements.txt,
    environment.yml, Pipfile, install.R, apt.txt, postBuild,
    runtime.txt, Dockerfile, default.nix. Produces a Dockerfile.
    Stops at: no env files -> bare python:3.11; pyproject.toml
    without a lockfile; compiled deps beyond apt.txt (CUDA, MKL,
    custom C libs).
  • Cloud Native Buildpacks (pack): ordered buildpack list; first
    match wins. Stops at: needs Procfile / entry point; doesn't fit
    scientific workflow shapes (Nextflow, Snakemake, papermill); emits
    OCI images, not inspectable Dockerfiles.
  • docker init: interactive prompt; not a fit for automation.
  • Devcontainer templates: static templates keyed on
    .devcontainer/devcontainer.json presence + language; requires
    operator to pick a template.
  • Nix flake generators: minimal skeleton, not repo-analysis-driven.

Where LLM tier earns its place

Concrete edge cases the deterministic tools do not handle today:

  • Compiled deps beyond apt.txt (repo mentions PyTorch + CUDA
    version in README prose; no lockfile encodes the CUDA choice).
  • Non-buildpack workflow shapes (snakemake --cores 8,
    nextflow run main.nf, papermill notebook.ipynb -p param 3).
  • System prerequisites in README prose that no deterministic tool
    parses (Install OpenBabel first, then run pip install .).
  • pyproject.toml with editable install (pip install -e .) but no
    lockfile -- repo2docker punts.
  • Multi-stage builds where the researcher's own tool must be compiled
    before the experiment runs (Layer 1 vs Layer 2 per #415).

Proposed shape

Same pass shape as sieve controls:

sieve = [
  ("repo2docker",  detect: any env file in the list above),
  ("buildpacks",   detect: `pack builder inspect` returns a match),
  ("heuristic",    detect: single-language repo with one obvious lockfile),
  ("llm_eval",     always-runs-if-preceding-inconclusive; prompt: file
                    listing, top-level READMEs, detected language
                    signals, evidence of compiled-deps),
  ("manual",       operator prompt with best-effort skeleton to edit),
]

Each pass either produces a Dockerfile + justification, or falls
through. LLM output is a candidate, not a conclusion (Constitution
IV -- Never Guess User Values). Operator confirmation gates
application; the artifact is not written into the repo silently.

Scope

  • Design the sieve above.
  • Prototype the deterministic tier via repo2docker's Python API
    (repo2docker.Repo2Docker) as the reference integration.
  • Design the LLM tier's prompt shape and evidence bundle (leans on
    the LLM-reasoning-capture work from #421 -- prompt and reasoning
    MUST land in a durable artifact next to the Dockerfile).
  • Decide artifact surface: Dockerfile vs devcontainer.json vs both;
    where it lands in the repo; what darnit records in the attestation.

Non-goals for v0

  • Rewriting repo2docker's or buildpacks' detection logic.
  • Nix flake generation (narrow audience; revisit once the sieve
    shape stabilizes).
  • Runtime execution verification (that's the ambitious Option C from
    the design conversation -- separate issue if pursued).
  • Auto-applying LLM-generated Dockerfiles without operator sign-off.

Constitution alignment

  • I. Plugin Separation: the sieve lives inside
    darnit-reproducibility; darnit core doesn't grow a Docker
    dependency.
  • II. Conservative-by-Default: LLM tier produces candidates, not
    conclusions.
  • IV. Never Guess User Values: operator sign-off is a hard
    precondition to writing anything into the repo.
  • V. Sieve Pipeline Integrity: the deterministic->LLM->manual
    ordering is the same pattern the control sieve uses; each pass
    either conclusively produces an artifact or hands off.

Related

  • #414 (signal extraction module) -- the sieve's detect signals are
    the same signals this feeds.
  • #415 (layer + tightness taxonomy) -- the produced environment
    should declare which (layer, tightness) it targets.
  • #416 (heuristic checks) -- an audit that finds "no environment
    declaration" is the trigger; this issue is the remediation half.
  • #421 (LLM reasoning capture) -- prerequisite for LLM tier's output
    being auditable.
  • #418 / #419 / #420 (determinism set) -- companion; the whole point
    of a hermetic env is to make audit + remediation more
    deterministic downstream.
Lenguaje dominante
Python
Estrellas
22
Forks
27
Merge medio
1 d 19 h
PR fusionados (30 d)
39

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de darnitdevorg/darnit

Todos los issues de darnitdevorg/darnit

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.