refactor: follow the cl-prolog-kit / cl-dataflow-kit rename - #2
Open
takeokunn wants to merge 4 commits into
Open
refactor: follow the cl-prolog-kit / cl-dataflow-kit rename#2takeokunn wants to merge 4 commits into
takeokunn wants to merge 4 commits into
Conversation
nerima-lisp/cl-prolog was renamed to cl-prolog-kit (v1.5.0) and cl-dataflow to cl-dataflow-kit (v1.2.0). The ASDF system names and CL package names moved with the repositories, so `cl-prolog:` no longer resolves and `:depends-on "cl-prolog"` no longer finds a system. Updated here: the flake input's Nix variable name and URL, the ASDF :depends-on entries, every package-qualified symbol reference, and the prose that names either package. flake.lock was regenerated with `nix flake lock`, not hand-edited. This also moves the pin forward to the current release rather than carrying the old one, since the tag the old pin named no longer contains a system under the old name.
The nshell-0.4.0 derivation failed with "ASDF program-op did not create executable nshell" even though the build itself succeeded. cl-nix-forge's mkExecutable defaults to looking for the dumped image at $out/<lispSystem>, i.e. $out/nshell, but ASDF's :build-pathname "nshell" resolves relative to this system's own :pathname "src", so program-op writes it to $out/src/nshell -- confirmed by the fixupPhase RPATH-shrink log naming that exact path. Setting programPath explicitly is what mkExecutable's own docstring says to do at this boundary. This failure predates the rename: main's CI has been red on the same derivation since 2026-08-10.
…via PATH Two e2e tests hardcoded host-only absolute paths (/usr/bin/printf, /bin/echo) to force nshell to spawn a genuine external process instead of dispatching to its own builtin of the same name (echo and printf are both nshell builtins, and a bare name always resolves to the builtin ahead of PATH -- see resolve-command-path). Darwin's sandbox-exec profile and the non-sandboxed integration-test dev shell both expose /usr/bin and /bin, so this worked there, but the fully-sandboxed x86_64-linux Nix build used by the "nix flake check" CI job grants no host filesystem visibility beyond declared build inputs, so those paths do not exist and command resolution correctly reported exit 127 / "not found". These tests could not run against a real build until today, since the nshell-0.4.0 derivation itself failed to build until the mkExecutable output-path fix landed, so this is now-exposed rather than newly broken. Resolve the target binary through nshell.domain.completion:command-path-candidates against the real PATH the spawned nshell subprocess inherits, the same mechanism nshell itself uses to resolve external commands, instead of guessing a host path.
`packages.releaseBundle` has pointed at `deliveryFor`'s thin `ctx.executable.overrideAttrs` wrapper since the "Merge public readiness tooling" merge commit 3252dfb (2026-08-08). That merge kept parent 2's (e014d9b) `scripts/verify-release-bundle.pl` verbatim but discarded that same commit's ~130-line `releaseBundle` derivation -- the one that actually produced the `libexec/nshell` + relocated `lib/*.so` + glibc-interpreter layout the checker asserts -- in favour of parent 1's simpler `deliveryFor`. `deliveryFor`'s `$out/bin/nshell` is a `makeWrapper` script that execs a Lisp core through this machine's own Nix store and cannot run anywhere else, so `build release binary` (ci.yml, ubuntu-latest) has failed with "missing Linux release file: libexec/nshell" on every run since, masked until today by two earlier, unrelated breaks in the same job (a stale flake.lock dependency and `mkExecutable`'s `programPath` default, fixed on this branch by 840cb08). Restores e014d9b's derivation as `releaseBundleFor`, adapted to read the dumped image from `${ctx.executable}/bin/nshell.cl-nix-forge-unwrapped` (cl-nix-forge v0.5.0's own internal path for the `program-op` output, since `ctx.package` predates that dump) instead of the old bespoke `mkNshell` derivation, and reusing `deliveryFor`'s README/LICENSE/man-page installation instead of repeating it a second time. Linux only: SBCL on Darwin takes `mkExecutable`'s documented `.core`-plus-wrapper fallback, which has no Mach-O binary to relocate, and `build release binary` has never run on Darwin (ci.yml deleted its macos-14 leg outright, not merely disabled it) -- so `releaseBundleFor` falls back to `deliveryFor` there, matching what already built successfully pre-fix, rather than inventing an unverified Darwin bundling scheme. Also fixes `scripts/verify-release-bundle.pl`'s Nix-store-reference scan: `File::Find::find` only follows a symlink it meets while descending, and given one as its own root -- exactly what `result` is, and what both ci.yml and this script's own usage line pass it as -- it visits that one entry and never opens the directory it points to, so the scan has silently covered zero files under every invocation anyone has actually run. Resolved with `Cwd::abs_path` before the walk; confirmed live on this machine's own (non-portable, Darwin-fallback) build, which now correctly fails the check it always should have failed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nerima-lisp/cl-prologwas renamed tocl-prolog-kit(v1.5.0) andcl-dataflowtocl-dataflow-kit(v1.2.0). The ASDF system names and CL package names moved with the repositories, socl-prolog:no longer resolves and:depends-on "cl-prolog"no longer finds a system.Updated: flake input variable names and URLs, ASDF
:depends-on, every package-qualified symbol reference, and prose.flake.lockregenerated withnix flake lock, never hand-edited. The pin moves forward to the current release because the tag the old pin named no longer contains a system under the old name.Deliberately NOT renamed:
cl-prolog2(an unrelated third-party SWI-Prolog binding),optimizer-dataflow*.lisp(generic compiler dataflow-analysis, verified to contain zerocl-dataflowreferences), thecl-cc-prolog-toolssystem name (the substring iscc-prolog), and file names carrying a bareprologtopic word.Verification before pushing: residual grep for the old names in all four case spellings returns zero hits (excluding the
cl-prolog2lines), nokit-kitdouble suffix, and(/)counts byte-identical per.lisp/.asdfile before and after — the source change is rename-only. CI here is the build verification.