aboutsummaryrefslogtreecommitdiffstats
path: root/packaging/stage.sh (follow)
Commit message (Collapse)AuthorAge
* release: 0.1.1, and stop the CLI carrying a second versionuser2026-08-12
| | | | | | | | | | | | | | Published 0.1.1 with the dead-session and flaky-read fixes. Also removes the `sl0ppi-cli` line from MANIFEST and the version field from cli/package.json: the CLI ships as part of the product, so a version of its own only drifts -- a 0.1.1 release shipped a MANIFEST claiming sl0ppi-cli 0.1.0. Records the terminal-level flakiness as a known issue with the measurements, so it is a tracked defect rather than folklore: list-tabs/list-panes fail ~60% of the time against a detached live session on a 2-vCPU box, ~25% with a client attached, and the action client blames "no active session" for what is really a transient enumeration failure.
* build: ship the sl0ppi CLI in the tarballuser2026-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The artifact was stale twice over: it predated the protobuf fix and did not contain the CLI at all. Both fixed, and the whole chain re-verified from the tarball rather than assumed. The CLI ships as a single 31K file (`bun build --target=bun`) run by the bundled bun, rather than a source tree or a second `--compile`d binary that would embed another 90M copy of bun. `install.sh` generates the wrapper and pins SL0PPI_BIN to the sl0ppij it just installed, so the orchestrator can never end up driving some other zellij that happens to come first on PATH. Verified in a throwaway HOME with node, npm, bun, cargo, rustc and python3 all replaced by poison stubs that fail loudly if invoked: sl0ppij --version -> 0.45.0+sl0p1 (static musl, no libc dependency) pi --version -> 0.84.1 (bundled bun) sl0ppi doctor -> all good sl0ppi init x2 -> two projects scaffolded sl0ppi up -> session "dev", 2 tabs, agents suspended sl0ppi ls -> agent:suspended, 1 pane each sl0ppi up (again) -> "up to date" And the promise the whole thing exists for, end to end: attach a client, press Enter in the suspended agent pane, and pi starts on the bundled runtime -- while the other project's agent stays suspended, because only the focused pane got the key. `make test` now runs the CLI suite alongside the Rust ones, so the two halves cannot drift apart unnoticed.
* build: ship a static musl binary instead of a glibc-2.39 oneuser2026-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | The gnu release build required GLIBC_2.39 (Jan 2024), so the "install it on another machine" artifact would have failed on Debian 12, Ubuntu 22.04 and RHEL 9. That is the whole premise of this repo, so it is a defect, not a nit. make build -> cargo zigbuild --target x86_64-unknown-linux-musl result -> ELF, statically linked, 0 GLIBC_ symbols, 51M make build-gnu kept for fast local use A musl build needs a musl C toolchain: isahc/curl pulls libz-sys and libnghttp2-sys unconditionally (confirmed: --no-default-features does not drop them). cargo-zigbuild + the ziglang python module were already installed here, so this needs no sudo, no docker daemon and no system packages. stage.sh now refuses to be quiet about it: it reports "statically linked" or warns loudly that the artifact inherits the build box's libc. Re-verified from the tarball in a throwaway HOME with node/npm/bun/cargo replaced by poison stubs: static binary, pi 0.84.1 on the bundled bun, both wasm plugins installed, session starts under a pty with no errors. Remaining libc floor is bun's own glibc 2.17 (2012); bun publishes a musl build if Alpine ever matters.
* build: ship sl0pstatus, and install every plugin the package carriesuser2026-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Phase 3: `make package` now produces a tarball that provably works on a machine with no node, npm, bun or rust. Two bugs the clean-room test found, neither visible until a session actually started: - the default layout builds its status bar out of zjstatus, which we were not shipping at all (vendored as sl0pstatus/ in the preceding commits) - install.sh installed a hardcoded plugin list, so zjstatus.wasm would not have reached the config dir even once staged Also: layouts/*.kdl still pointed at ~/.config/zellij, missed by the rename pass because that pass only rewrote config.kdl. Verified end to end, from the tarball, in a throwaway HOME with node/npm/bun/ cargo shadowed by stubs that fail loudly if invoked: sl0ppij --version -> sl0ppij 0.45.0+sl0p1 pi --version -> 0.84.1 (on the bundled bun) pir --help -> ok sl0ppij -s realtest -> session starts under a pty, config "Well defined", fork pane titles render, both wasm plugins load, no errors beyond the first-run permission cache Artifact: sl0ppi-0.1.0-x86_64-linux.tar.gz, 83M, + .sha256.
* build: follow the rename through config, packaging and docsuser2026-08-12
| | | | | | | | | | | | | | | | config/config.kdl plugin path -> ~/.config/sl0ppij/plugins, builtin plugins -> the sl0ppij: URL scheme. Verified to load under the renamed binary ("[CONFIG FILE]: Well defined."). install-config.sh syncs to ~/.config/sl0ppij install.sh a stock zellij on the target is no longer a warning, it is just a fact: the two coexist stage.sh drops the "renaming at package time is a fig leaf" note Makefile builds `-p zellij` (package) and ships `sl0ppij` (binary); `make check` now also gates the root package, using the prebuilt asset plugins so it does not need debug wasm docs/ rename.md records what was done, what was deliberately left (plugin-internal strings live in prebuilt wasm), and the verification actually performed
* build: scaffold versioning, docs and the packaging pipelineuser2026-08-12
Adds the layer that makes this a distributable product rather than three directories: VERSION one sl0ppi version for the whole monorepo FORKS.md what each component is based on, and how to rebase the fork Makefile build / vendor / stage / package, plus dev-box helpers packaging/ fetch pinned payloads, assemble an install tree, install it docs/ architecture, the rename plan, the roadmap The self-contained runtime question is settled and verified: pi upstream builds its own release binary with `bun build --compile`, and a vendored bun runs the vendored pi dist unmodified, so the tarball carries bun + pi and needs no system node, npm or rust on the target machine. packaging/install.sh does a per-user install under ~/.local, never clobbers an existing config (writes .new alongside, or backs up under --force-config), and warns loudly when a stock zellij is present -- because until docs/rename.md is implemented the binary is still zellij underneath and would collide with it.