Forks and pins
sl0ppi ships one version (see VERSION), but it is assembled from upstream
projects we fork or pin. This file is the transparency record: for every
component, what it is based on and how far it has drifted.
Keep this file honest. Update it in the same commit that moves a base.
Vendored forks
sl0ppij ← zellij
| upstream | https://github.com/zellij-org/zellij |
| upstream version | 0.45.0 |
| upstream base commit | 0e6e4404 — Support the Kitty Image Protocol (#5428), 2026-07-31 |
| our version string | 0.45.0+sl0p1 |
| lives at | sl0ppij/ |
| patches on top | 62 commits (all prefixed sl0p:) |
| license | MIT (upstream sl0ppij/LICENSE.md retained) |
The 62 fork commits were replayed into sl0ppij/ from the standalone fork repo
(ssh://git@git.sl0p.foo:39327/srv/git/sl0ppij.git, branch sl0p/base), so
git log --oneline sl0ppij/ is the patch series. Upstream's own 3311 commits
were squashed into a single vendor import to keep the monorepo small.
How to rebase onto a new zellij release
The fork commits live under a sl0ppij/ prefix here, which upstream's tree does
not have, so a rebase happens outside the monorepo and comes back as patches:
# 1. in a scratch clone of the standalone fork repo
git remote add upstream https://github.com/zellij-org/zellij # if missing
git fetch upstream
git rebase --onto upstream/main <old-base> sl0p/base # resolve conflicts
# 2. re-import into the monorepo
git -C <fork> archive <new-upstream-base> | tar -x -C sl0ppij/ # new vendor import (own commit)
git -C <fork> format-patch --binary -o /tmp/p <new-base>..sl0p/base
git am --directory=sl0ppij /tmp/p/*.patch
# 3. verify the import is byte-identical, then update this file
test "$(git rev-parse HEAD:sl0ppij)" = "$(git -C <fork> rev-parse sl0p/base^{tree})"
The standalone fork repo stays alive purely as the rebase workbench; the monorepo is authoritative for what ships.
sl0pstatus ← zjstatus
| upstream | https://github.com/dj95/zjstatus |
| upstream version | 0.24.0 |
| upstream base commit | 74f36b4 — chore: bump version to v0.24.0, 2026-07-15 |
| lives at | sl0pstatus/ |
| patches on top | 3 commits (double-click a tab to rename; a new-tab button and pane-gap margins; the bar as a framed box) |
| builds to | zjstatus.wasm (cargo package name is still zjstatus) |
| standalone repo | ssh://git@git.sl0p.foo:39327/srv/git/sl0pstatus.git, branch sl0p |
Not optional decoration: config/layouts/default.kdl replaces zellij's stock
tab-bar and status-bar with this plugin, so without it the default layout starts
with a "failed to load plugin from disk" error and no status bar.
It depends on the released zellij-tile 0.44.3 from crates.io, not on
sl0ppij's in-tree one — the plugin API is stable across that gap. Our build
reproduces the previously hand-built zjstatus.wasm in the live config dir
byte-for-byte.
Fork-only config keys, all inert when unset (upstream renders identically):
| key | what it does |
|---|---|
margin_left / margin_right |
blank columns at each end, so the bar lines up with panes inset by the pane gap |
new_tab |
format for the {new_tab} widget, a clickable button that opens and focuses a tab |
bar_frame_enabled |
draw the bar as a box in the pane style, when its pane has 3+ rows |
bar_frame_rounded |
╭╮╰╯ vs ┌┐└┘; keep in step with rounded_corners in config.kdl |
bar_frame_format |
style for the box glyphs (we use the theme's frame_unselected) |
Its tests do not run under make test. The crate builds for
wasm32-wasip1 and .cargo/config.toml points the test runner at wasmtime,
which is not installed here. Run them against the host instead:
cd sl0pstatus && cargo test --lib --target x86_64-unknown-linux-gnu
Same rebase procedure as sl0ppij, with sl0pstatus/ as the prefix.
Pinned, not forked
pi (the agent)
| upstream | npm @earendil-works/pi-coding-agent |
| pinned version | 0.84.1 |
| vendored at | (not yet — see docs/roadmap.md phase 3) |
Our extensions in pi-ext/ target this version's extension API. pi is not
forked; it is pinned and redistributed as-is.
bun (the runtime)
| upstream | https://bun.sh |
| pinned version | 1.3.14 |
| why | pi is a Node/TS program; bun runs dist/cli.js directly (verified) and is a single static binary, so the tarball needs no system Node |
| which build | bun-linux-x64-**baseline**.zip. The default build needs AVX2 and dies with Illegal instruction on a plain KVM guest — measured under qemu-x86_64 -cpu Nehalem, where baseline prints its version and the default one crashes. |
pi upstream builds its own release binary with bun build --compile, so bun is
a supported runtime for it rather than a gamble.