Restore devenv shell entry under the devenv 2.1.2 CLI #26

Merged

vnprc merged 1 commit from agent/devenv-shell-git-hooks-pin into master

2026-10-07 03:04:08 +01:00

vnprc-agent commented

2026-10-07 02:54:39 +01:00

Collaborator

devenv shell in this repo stopped working, and this restores it. Nothing about the Rust toolchain moves: rustc is still 1.86.0 and the MSRV pins in roles/Cargo.lock are untouched, because nixpkgs, rust-overlay and the devenv modules all keep their current revisions. Two lines of cause: the fleet's move to nixos-26.05 bumped the devenv CLI from 1.11.1 to 2.1.2, and the new CLI stopped tolerating two things this repo had been getting away with. First, it no longer silently adds the git-hooks input that the pinned devenv modules demand, and it deletes that input from devenv.lock on every run, which is why the lock kept showing up modified. Second, two tasks declared ordering against process tasks that this devenv version does not define at all; the old CLI warned and carried on, the new one stops. What proves it: devenv shell now reaches a prompt with rustc 1.86.0 and gcc 14.2.1, and devenv.lock is byte-identical across three consecutive runs instead of being rewritten each time. If this is wrong, revert the commit — it touches only devenv.yaml, devenv.nix and devenv.lock, and nothing outside the dev shell reads them.

One thing worth knowing, not changed here: those process-task dependencies never resolved, so create:dirs and build:cdk:cli have had no trigger at all. Log and database directory creation and the cdk-cli build have not been running ahead of devenv up. Rewiring them is a follow-up.

Refs vnprc/hashpool#25

What changed

devenv.yaml declares a git-hooks input pinned to 80479b6ec16fefd9c1db3ea13aeb038c60530f46, the revision the committed lock already carried. devenv.nix loses the before lists from tasks."create:dirs" and tasks."build:cdk:cli". devenv.lock records the now-explicit input; its only other movement is flake-compat resolving from the pinned git-hooks revision's own lock rather than the revision the old CLI injected, which no evaluated path here uses.

Why not simply update

Approach	Result
Full `devenv update`	Fixes both faults but bumps `nixpkgs`, moving `rustc` off 1.86.0 and breaking the MSRV pins
`devenv update devenv` alone	Keeps `nixpkgs`; modules then define `devenv:processes:*`, but their `git-hooks.nix` needs `cspell`, absent from the pinned May-2025 `devenv-nixpkgs`
Current modules, `git-hooks` pinned back	`error: infinite recursion` at `src/modules/integrations/git-hooks.nix:22`

Staying pinned is the only one of the four that works without moving the toolchain. Syncing the whole stack is a deliberate, separately validated piece of work, not a side effect of repairing shell entry.

Risk

R1. The change touches three dev-shell files and no runtime, provisioning, secret or persistent state; .devenv/state is untouched, so the regtest chain and the wallet and mint databases are unaffected. The witness is immediate and was executed rather than reasoned about: the shell either enters or it does not. Rollback is a straight revert of one commit.

Validation

devenv shell enters and reports rustc 1.86.0 and gcc (GCC) 14.2.1.
devenv.lock has the same MD5 after each of three consecutive devenv shell runs, confirming the drift is gone.
devenv tasks list shows create:dirs and build:cdk:cli present, and shows no devenv:processes:* task, which is the direct evidence that the removed dependencies were dead rather than merely reordered.
The lock diff moves no nixpkgs, rust-overlay or devenv revision.

Not run: cargo check on protocols/, because a fresh worktree has no protocols/Cargo.lock and hits the known time 0.3.55 MSRV resolution noted in the issue about that lock, which is unrelated to shell entry.

`devenv shell` in this repo stopped working, and this restores it. Nothing about the Rust toolchain moves: `rustc` is still 1.86.0 and the MSRV pins in `roles/Cargo.lock` are untouched, because `nixpkgs`, `rust-overlay` and the `devenv` modules all keep their current revisions. Two lines of cause: the fleet's move to `nixos-26.05` bumped the `devenv` CLI from 1.11.1 to 2.1.2, and the new CLI stopped tolerating two things this repo had been getting away with. First, it no longer silently adds the `git-hooks` input that the pinned `devenv` modules demand, and it deletes that input from `devenv.lock` on every run, which is why the lock kept showing up modified. Second, two tasks declared ordering against process tasks that this `devenv` version does not define at all; the old CLI warned and carried on, the new one stops. What proves it: `devenv shell` now reaches a prompt with `rustc` 1.86.0 and `gcc` 14.2.1, and `devenv.lock` is byte-identical across three consecutive runs instead of being rewritten each time. If this is wrong, revert the commit — it touches only `devenv.yaml`, `devenv.nix` and `devenv.lock`, and nothing outside the dev shell reads them. One thing worth knowing, not changed here: those process-task dependencies never resolved, so `create:dirs` and `build:cdk:cli` have had no trigger at all. Log and database directory creation and the `cdk-cli` build have not been running ahead of `devenv up`. Rewiring them is a follow-up. Refs vnprc/hashpool#25 ### What changed `devenv.yaml` declares a `git-hooks` input pinned to `80479b6ec16fefd9c1db3ea13aeb038c60530f46`, the revision the committed lock already carried. `devenv.nix` loses the `before` lists from `tasks."create:dirs"` and `tasks."build:cdk:cli"`. `devenv.lock` records the now-explicit input; its only other movement is `flake-compat` resolving from the pinned `git-hooks` revision's own lock rather than the revision the old CLI injected, which no evaluated path here uses. ### Why not simply update | Approach | Result | | --- | --- | | Full `devenv update` | Fixes both faults but bumps `nixpkgs`, moving `rustc` off 1.86.0 and breaking the MSRV pins | | `devenv update devenv` alone | Keeps `nixpkgs`; modules then define `devenv:processes:*`, but their `git-hooks.nix` needs `cspell`, absent from the pinned May-2025 `devenv-nixpkgs` | | Current modules, `git-hooks` pinned back | `error: infinite recursion` at `src/modules/integrations/git-hooks.nix:22` | Staying pinned is the only one of the four that works without moving the toolchain. Syncing the whole stack is a deliberate, separately validated piece of work, not a side effect of repairing shell entry. ### Risk R1. The change touches three dev-shell files and no runtime, provisioning, secret or persistent state; `.devenv/state` is untouched, so the regtest chain and the wallet and mint databases are unaffected. The witness is immediate and was executed rather than reasoned about: the shell either enters or it does not. Rollback is a straight revert of one commit. ### Validation - `devenv shell` enters and reports `rustc 1.86.0` and `gcc (GCC) 14.2.1`. - `devenv.lock` has the same MD5 after each of three consecutive `devenv shell` runs, confirming the drift is gone. - `devenv tasks list` shows `create:dirs` and `build:cdk:cli` present, and shows no `devenv:processes:*` task, which is the direct evidence that the removed dependencies were dead rather than merely reordered. - The lock diff moves no `nixpkgs`, `rust-overlay` or `devenv` revision. Not run: `cargo check` on `protocols/`, because a fresh worktree has no `protocols/Cargo.lock` and hits the known `time` 0.3.55 MSRV resolution noted in the issue about that lock, which is unrelated to shell entry.

vnprc-agent added 1 commit

2026-10-07 02:54:39 +01:00

Restore devenv shell entry under the devenv 2.1.2 CLI e09a738140

Pin a git-hooks input and drop dead process task dependencies.

The 1.x CLI injected git-hooks into devenv.lock implicitly, which is why
the committed lock carried it while devenv.yaml never declared it. The
2.1.2 CLI strips it on every run, and the devenv modules revision pinned
in the lock still throws without it. Declaring it explicitly at the
revision the lock already carried settles the drift and leaves nixpkgs,
rust-overlay and devenv untouched, so rustc stays 1.86.0 and the MSRV
pins in roles/Cargo.lock are unaffected.

The before lists on create:dirs and build:cdk:cli named devenv:processes:*
tasks that this devenv version does not define; 1.11.1 reported that as a
soft TasksNotFound and continued, 2.1.2 treats it as fatal.

Refs vnprc/hashpool#25