Installation
binpm is distributed as first-party release artifacts. Install flows are designed for macOS x64, macOS arm64, Linux x64, Linux arm64, Windows x64, and Windows arm64 hosts.
Homebrew
On macOS and Linux:
The Homebrew formula uses prebuilt binpm release archives for:
darwin/amd64darwin/arm64linux/amd64linux/arm64
Direct Installers
Direct installers are for users who want a release artifact without Homebrew or cargo-binstall. Install cosign first and leave it on PATH; the installers require it to verify SHA256SUMS entries and Sigstore bundle sidecars (*.sigstore.json) with cosign verify-blob --bundle. Missing cosign is a prerequisite failure, not a reason to disable verification. If you do not want to manage that prerequisite directly, use Homebrew or cargo-binstall instead.
macOS and Linux:
Windows PowerShell:
These commands fetch the current first-party installer scripts from delinoio/oss. For reproducible automation, pin the same raw URL paths to a reviewed commit or repository tag instead of refs/heads/main, and replace latest with an explicit binpm semver.
The canonical in-repo installer paths remain:
scripts/install/binpm.shscripts/install/binpm.ps1
From a repository checkout, maintainers can run the scripts directly:
Direct installers detect unsupported x86 hosts before resolving release tags or downloading assets. Use an x64/arm64 host or a supported CI image when an installer reports an unsupported host.
Direct installers support bundle-enabled releases only.
Direct installers place the binary in ~/.local/bin by default and do not modify your shell PATH. Add that directory before verifying the install, or pass --install-dir / -InstallDir with a directory already on PATH.
macOS and Linux:
Windows PowerShell:
cargo-binstall
binpm's cargo-binstall metadata resolves first-party GitHub Release assets only. Third-party quick-install and compile fallback strategies are disabled by contract.
GitHub Actions
Verify the Install
Run these commands in a shell where binpm resolves on PATH:
binpm doctor verifies that the binary can inspect local and global binpm state. binpm env --shell bash verifies shell-specific PATH command generation without mutating shell profile files.
Supported Release Assets
binpm can install release assets distributed as:
- Bare executable assets.
.tar.gzand.tgzarchives..tar.xzand.txzarchives..tar.zstarchives..ziparchives.
On POSIX hosts, archive installs write the selected binary with executable permissions. Zip archives that omit Unix executable metadata can still install when the expected binary name and target-aware path tokens identify exactly one member; otherwise binpm fails and asks for an explicit bin value instead of guessing.
Global Home
Global installs use ~/.binpm:
~/.binpm/bin: globally installed executable links or copies.~/.binpm/packages: global installed package records.~/.binpm/cache: user-level asset cache.
PATH Setup
Global installs place executables under ~/.binpm/bin. When that directory is not on PATH, global install output and binpm doctor print guided setup messaging.
Use binpm env to print shell-specific PATH commands:
Supported --shell values are bash, zsh, fish, and powershell. PowerShell is accepted case-insensitively. cmd is recognized but explicitly deferred and returns an unsupported-shell diagnostic.
binpm does not edit shell profile files from these commands. Persistent profile changes are opt-in: add only the printed global bin command to your shell profile when you want global installs to persist on PATH. The printed project-local command is for the current project or shell session only.
Security Boundary
Release installers verify binpm's own published release artifacts. That release verification is separate from binpm's package-asset verification for tools installed by binpm.
binpm package installs use HTTPS source-provider APIs and release asset URLs. Stored URLs are sanitized so query strings, fragments, credentials, and expiring signed URL details are not written into project files.
When strict verification is requested for installed tools, --require-verified and binpm verify --require-verified fail unless a trusted provider digest is available. Checksum sidecar discovery, checksum manifest discovery, and signature verification for packages installed by binpm remain implementation work.