Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#1,159 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
build-system, compilers, documentation, tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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".

Dominant language
C
Stars
3
Forks
7
Avg merge
4h 15m
Merged PRs (30d)
106

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InauguralSystems/EigenScript

All issues in InauguralSystems/EigenScript

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.