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

Packages: a manifest cannot declare that a package needs a runtime build variant (http/gfx/zlib/net) — the failure is an undefined builtin at import, not a clear message at install

Abierto
#1,159 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
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c

Línea de trabajo

Start with docs/PACKAGE_SPEC.md and the capability probe used by run_all_tests.sh, then trace the package install/verify and import paths. Check how eigs-package-template is structured. Done means the manifest field is documented and templated, mismatches fail clearly during install or verification, and unmet variants produce a named import-time error.

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

Descripción

area:packages enhancement

Gap

The runtime's zero-dependency property is about the C build (libc/libm, or the freestanding HAL), and packages are EigenScript source vendored as git checkouts (docs/PACKAGE_SPEC.md) — install runs no code, import runs it inside whatever binary the user has. Those two layers are compatible by design. But a package can legitimately require a runtime EXTENSION: an HTTP client library needs the http variant (http_* builtins), a UI helper needs gfx, a compression helper needs zlib, a socket helper needs net.

Today eigs.json has name, version, deps (and lint.allow) — no way to say "this package needs variant X". So on a make (default) binary, a package that calls http_post fails at first use with an undefined-variable error deep inside the package, long after --pkg install said everything was fine, and the user has no way to know it was a build-variant problem rather than a broken package.

Ask

  1. A manifest field, e.g. "requires": ["http"] (values = the runtime's variant names), documented in PACKAGE_SPEC.md.
  2. --pkg install / --pkg verify check the running binary's capability set (the runtime already knows which extensions it was built with — the same probe run_all_tests.sh uses to gate the HTTP sections) against every installed package's requires, and print one clear line per mismatch: which package, which variant, which make target provides it. Exit nonzero on mismatch (loud, per the fail-soft reform).
  3. import <leaf> on a package whose requires is unmet raises a named error at import time ("package X requires the http variant; this binary was built without it"), not an undefined variable at the first call.
  4. eigs-package-template gets the field with an empty list.

Why now

The package system has zero real consumers (every ecosystem eigs.json is a project-root marker with deps: {}); the first planned edges (a SAT portfolio consumer → EigenMiniSat; iLambdaAi → the ouroboros frontend) are pure EigenScript and will not hit this, but an HTTP or UI helper package is the obvious third, and this is the first thing it would hit. Filed so the gap is named before the edge, per CLAUDE.md's "surface the gap, don't work around it".

Lenguaje dominante
C
Estrellas
3
Forks
7
Merge medio
4 h 7 min
PR fusionados (30 d)
112

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 InauguralSystems/EigenScript

Todos los issues de InauguralSystems/EigenScript

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.