Punix v2¶
# Punix v2
Install tools, set up machines, deploy apps — without breaking anything.
A package manager and service deployer for macOS and Linux. Every install is reversible. Every deploy can be rolled back in one second. Works the same on your laptop, your VPS, and any host you can reach over SSH.
Get Punix in one command.¶
macOS, Linux, or WSL. The installer prints what it will do and pauses before doing it.
Or pip install punix — see other installation paths.
What Does Punix Do?¶
Punix installs the command-line tools and applications you need across macOS, Linux, and WSL — into a per-user profile, atomically. It won't install files outside ~/.punix/.
Each package lands in its own hash-named directory inside ~/.punix/store/<hash>-<name>-<version>/. The hash binds the recipe and its sources; two versions of the same tool can coexist because they have different hashes and different directories.
Your active profile is a directory of symlinks at ~/.punix/current/bin/, which you add to your $PATH once. A binary on your $PATH points into its store entry. Multiple deps can require different openssl versions without conflict.
Switch profiles ("the set I had last week") with one command — the live state changes in a single syscall. Uninstall is exact and reversible. No leftover files, no broken symlinks. Plays nice with Homebrew if you have it.
The same recipe, every time. For years.¶
Recipes are written in PCL — the Punix Configuration Language. The type checker reads them end-to-end before any build runs. Typo? Missing dep? Bad URL? You see it instantly, with a file:line:col location — not at minute 11 of a 12-minute build.
When a recipe and its sources are bytewise identical, the output is too. Bit-for-bit. Your install today and your install in 2027 produce the same binary, even if the upstream tarball server is long gone.
Roll back any deploy in one second.¶
Deploy your stack — config files, binaries, systemd or launchd units — in one command. Each deploy is a complete numbered snapshot. The previous one stays whole on disk.
If something breaks, punix service rollback flips you back instantly. It doesn't rebuild, doesn't reconfigure, doesn't replay anything — just points the live symlink at the previous snapshot. The whole operation is one os.replace syscall.
Power loss mid-deploy? The previous snapshot stays live. There is no half-deployed state.
Local, SSH, or your VPS — one command.¶
The deploy command takes a --target flag. Point it at local to deploy to your laptop, or ssh://you@server to deploy to your server. The workflow is identical: same config file, same build, same atomic flip, same one-second rollback.
Punix uses real ssh and rsync under the hood — no agent on the target, no daemon to install. The build closure is pushed by content hash, so only what's actually new gets transferred.
Why not just use…?¶
brew update can change installed paths underneath you. Punix coexists fine with brew.
NixRight shape, hard to learn, runtime-typed config. Punix has the same content-addressed store with a typed, lighter language.
AnsibleBuilt for orchestrating change on existing hosts. Punix replaces a host's app stack atomically — different job.
Docker ComposeHash-addressed layers, but YAML config and manual down/up rollback. Punix can drive a Compose stack as a backend.
Full comparison: vs Nix, Guix, SlapOS, Homebrew, Ansible, Docker →
Verified by tests, not marketing copy.¶
Every major property has a dedicated conformance test under tests/c_e2e/test_conformance_stage*.py. Any regression is a CI release-blocker — we don't ship if it fails.
What works today → · Corpus status → · Roadmap →