Skip to content

v1.22.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Sep 09:32
· 110 commits to main since this release
v1.22.0
69771e3

Added

  • Ten new adapters bring the total to thirty-five. pixi joins the regular set (on by
    default): a .pixi/ directory beside pixi.toml, pixi.lock or a pyproject.toml
    with a [tool.pixi] table is verified against pixi.lock read-only, because
    pixi lock --check can re-solve over the network and a verification must never do
    that. The other nine are opt-in like every build tree: Zig (.zig-cache/,
    zig-cache/ and zig-out/ beside a build.zig), Haskell Stack (.stack-work/),
    Haskell Cabal (dist-newstyle/; a lone .cabal file is never claimed), sbt
    (target/ and project/target/ beside build.sbt), and the imported-resource
    caches of Godot, Unity, Unreal, Defold and Cocos Creator. devp config set enable_zig true and friends switch them on, and every one is in the recommended
    set the config wizard offers. That makes thirty-five adapters, eighteen opt-in
    switches and forty-one settings; the whole opt-in class is walked through in
    docs/OPT_IN_BUILD_ADAPTERS.md.

  • devp caches clear docker --include-volumes (podman too): after the narrow
    reclaim, it lists the engine's unused volumes by name and takes one line of picks
    (numbers, ranges, all, or Enter for none), then runs one unforced volume rm <name> per pick. It is consent-gated end to end: it refuses --yes, --json and a
    piped stdin, and the pick list only arms within ten minutes of a completed volume
    dry run for that engine. Typed cold, the command becomes that dry run, and
    --include-volumes --dry-run ends by naming the command to type next. dev-prune
    still never runs volume prune or system prune --volumes anywhere, and the unit
    tests fail the build if any argv it assembles contains prune, --volumes or a
    force flag. nerdctl, finch and Apple's container get a usage error naming
    <engine> volume ls instead, because their volume listings cannot be sized safely.

  • A "Detected, but switched off" section at the end of a bulk dry run. When a
    dormant opt-in adapter would find bloat, devp run --dry-run now says so: how many
    repositories, and the exact devp config set enable_<name> true that would include
    them. The --json document carries the same facts under an additive
    recommendations key, and devp config set recommendations false silences the
    section once you have read it.

  • devp skill --detected and an editor detection report. Plain devp skill now
    ends by naming every editor and agent whose traces are on the machine or committed
    in the repository (home-directory footprints, VS Code-family extensions, rules
    files), and whether each one's rules are current, stale or missing. devp skill --detected then writes the right rules file for everything detected in one pass.
    Detection is pure existence checks; nothing is executed or fetched.

  • Exported rules files now carry three guardrails for the agents that read them: never
    delete a bloat directory by hand (use devp run, and devp restore to put back
    anything devp removed), never clear container volumes through a bulk engine prune,
    and never empty ~/.m2/repository uninvited.
    docs/IDE_INTEGRATION.md adds a copy-paste PreToolUse hook
    that turns the volume rule into a hard confirmation prompt in Claude Code.

Changed

  • The windowless Windows twin (devpw.exe) can no longer fall behind silently. The
    release publishes it as its own asset with a SHA-256 sidecar; devp update --install reconciles every twin alongside the main binary; devp doctor compares
    each twin's build stamp against the running version, names devp update --install
    as the fix, and exits 1 when the scheduled task is actually running a stale twin
    (a warning otherwise); devp doctor --fix performs the reconcile itself. The setup
    pass also self-heals once per version at an attended terminal. All of it stands
    down under DEV_PRUNE_OFFLINE, version_lock, and in development builds.

  • A worktree nested inside its own repository (the shape agent harnesses create under
    .claude/worktrees/) is no longer self-registered by the quiet Git hook or by
    status adoption. An explicit devp link still registers one when you mean it.

  • The no-longer-a-repository report now names both ways out in place (devp unlink <path> to drop the row, git init if the directory should be one again), and the
    nested-repository refusal explains why it exists (no lockfile of yours can vouch
    for someone else's git history) and points at the cache-relocation config for the
    common cause.

Fixed

  • devp restore in a Go repository rebuilds the recorded vendor/ directory again.
    It used to consult the directory the prune had already deleted to decide between
    go mod vendor and go mod download, so a pruned vendor tree came back as a
    module-cache download instead of the vendor/ the build was using.

  • devp trust --fix-ownership -y is honoured with the flag on either side of
    --fix-ownership. Previously one order asked anyway, which is what a script cannot
    answer.

  • DEV_PRUNE_NO_TUI=1 is honoured at every full-screen entry point, including the
    ones reached from inside another command, so agents driving a terminal never get a
    dashboard they cannot read.

  • The scheduled task's windowless twin, and a stray managed-binary alias, could be
    left running a stale release. Both are refreshed by comparing the new copy against
    the one already in place, and that comparison trusted two files with the same size
    and the same modified-time to also hold the same bytes, which is not guaranteed and
    occasionally false. A refresh that hit the coincidence quietly kept the old binary
    in place instead of replacing it. The comparison now always reads both files once
    their lengths match.

For contributors

  • crates.io publishing now uses Trusted Publishing: the release workflow exchanges a
    GitHub OIDC token for a 30-minute crates.io token at publish time, so the
    long-lived CARGO_REGISTRY_TOKEN secret is no longer read by the workflow.

  • Test fixtures create their repositories through git_in (an explicit -C on every
    invocation), so a test run started from inside a Git hook can never act on the
    repository that hosts the checkout.

Which download do I want?

Most people want none of them. The installers below verify the SHA-256
sidecar, put the binary somewhere already on PATH, and create the devp
alias — three things unzipping an archive does not do.

You are on Run this
Windows (PowerShell) iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex
Windows (Command Prompt) powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex"
macOS / Linux curl -fsSL https://devprune.vkrishna04.me/install.sh | sh
Python tooling uv tool install dev-prune==1.22.0 / pipx install dev-prune==1.22.0
Rust, no compile cargo binstall dev-prune@1.22.0
Rust, from source cargo install dev-prune --version 1.22.0 (needs Rust 1.88+)

The PyPI packages contain these same binaries rather than downloading one
afterwards, so they work behind a registry mirror and offline. cargo install
is the only channel that compiles on your machine; cargo binstall reaches
for the archives on this page instead.

Full instructions: https://devprune.vkrishna04.me/#install

The assets, then

Take one only if you are packaging dev-prune yourself, air-gapping it, or
pinning it into a container image.

Asset For
dev-prune-v1.22.0-windows-x64.zip Windows on Intel/AMD — almost every Windows PC
dev-prune-v1.22.0-windows-arm64.zip Windows on ARM — Surface Pro X, Snapdragon laptops, Windows in a Mac VM
dev-prune-v1.22.0-windows-x86.zip 32-bit Windows — locked-down corporate images, older industrial machines
dev-prune-v1.22.0-darwin-arm64.tar.gz Apple Silicon Macs — M1 and later
dev-prune-v1.22.0-darwin-x64.tar.gz Intel Macs — 2020 and earlier
dev-prune-v1.22.0-linux-x64.tar.gz Linux on Intel/AMD
dev-prune-v1.22.0-linux-arm64.tar.gz Linux on ARM — Raspberry Pi 4/5, Graviton, ARM CI runners

Both Linux builds are statically linked against musl, so they run on any
distribution including Alpine, with no glibc floor.

32-bit is published for Windows only. There is no 32-bit Linux, no 32-bit
macOS and no 32-bit ARM build on any platform; the install scripts refuse
rather than guess when they meet one.

There is no .vsix on this page. The VS Code extension has its own
version and its own release cadence, so it ships from its own tags:
the extension's releases.
Install it by name instead — VKrishna04.dev-prune, on the
VS Code Marketplace
and on Open VSX.

Windows: the binaries are not code-signed, and two separate features react
to that.

Windows protected your PC is SmartScreen, and it only challenges files
carrying a Mark of the Web — which your browser attaches to the download and
File Explorer copies onto everything it extracts. Clear the mark on the archive
before extracting and nothing inside it is ever marked:

Unblock-File .\dev-prune-v1.22.0-windows-x64.zip

The installers above already do this for you, on the archive and on both
installed copies.

A refusal with no dialog and no "run anyway" is something else: Smart App
Control, which blocks unsigned executables outright and never looks at the mark.
It is on by default on clean installs of Windows 11 22H2+ and always off on
upgraded ones, which is why the same release runs on one machine and not the
next. Unblock-File does not help, and neither does building from source.
The troubleshooting guide
covers what your options actually are.

Every archive ships a .sha256 sidecar. Check it before you trust it:

sha256sum -c dev-prune-v1.22.0-linux-x64.tar.gz.sha256
(Get-FileHash dev-prune-v1.22.0-windows-x64.zip).Hash -eq (Get-Content dev-prune-v1.22.0-windows-x64.zip.sha256).Split(' ')[0].ToUpper()

An archive's hash stops meaning anything the moment you unpack it, and the
unpacked files are the only ones your antivirus ever looks at. So each Windows
zip also ships a .zip.contents.sha256 listing the digest of every file inside
it — run this in the folder you extracted to, from Git Bash (sha256sum ships
with Git for Windows, and is what reads this format):

sha256sum -c dev-prune-v1.22.0-windows-x64.zip.contents.sha256

dev-prune.exe and devp.exe are one file under two names and share a digest
on purpose, so a scanner builds one reputation record instead of two.
devpw.exe — the console-free build the scheduled task runs — is compiled
separately and legitimately has a different one. devp trust prints the same
three digests for the copies already installed on your machine, so you can
compare them against this file without downloading anything again.

That sidecar proves the file was not altered in transit. It does not prove
where it came from — the same hand that swaps an archive swaps its sidecar.
Every archive on this page is also signed by GitHub's build provenance, which
binds it to this repository, this workflow and the commit it was built from:

gh attestation verify dev-prune-v1.22.0-linux-x64.tar.gz --repo Life-Experimentalist/dev-prune
gh attestation verify dev-prune-v1.22.0-windows-x64.zip --repo Life-Experimentalist/dev-prune

What's Changed

  • Release 1.22.0: ten new adapters, volume picks, devpw parity, editor detection by @VKrishna04 in #38

Full Changelog: v1.21.0...v1.22.0

Contributors

VKrishna04
Assets 39
Loading