magus v0.4.2 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
3 min read

Install on Windows

Warning

Nothing has run these binaries end to end. Both Windows targets are built by the release pipeline and never executed by it: windows/amd64 compiles and links natively, windows/arm64 is cross-compiled and is the newest, least proven target of all. windows/amd64 has shipped for several releases and has field use behind it; windows/arm64 has none.

The Buzz JIT is also newly enabled on Windows and its machine-code path has never run on a Windows machine here. If a magusfile gives a result that looks wrong, set BUZZ_JIT=0 and re-run - if the answer changes, that is a JIT bug and a very valuable report.

See platform support for the full matrix.

magus ships as a single self-contained binary. Download it with curl.exe, extract it into a PATH directory you own, then verify it before first run. Run these in PowerShell:

Quick install

# The hosted docs substitute the latest release tag below; on GitHub it reads
# literally - get the real value from https://github.com/egladman/magus/releases
$VERSION = "v0.4.2"
$ARCH = "amd64"       # or arm64 on Windows on ARM
curl.exe -fLO "https://github.com/egladman/magus/releases/download/$VERSION/magus_${VERSION}_windows_${ARCH}_static.tar.gz"
mkdir -Force $Env:USERPROFILE\bin | Out-Null
tar -xzf "magus_${VERSION}_windows_${ARCH}_static.tar.gz" magus.exe
Move-Item -Force magus.exe $Env:USERPROFILE\bin\magus.exe
magus version

The archive also carries LICENSE, THIRD-PARTY-NOTICES, README.md, and a BUILDINFO file naming the exact version, commit, platform, and variant. Naming magus.exe on the tar line above extracts just the binary; drop it to unpack all of them. BUILDINFO is readable without running anything, which is the point if a dynamically linked build will not start.

Both curl.exe and tar ship with Windows 10 (1803+) and Windows 11, so no extra tooling is needed. $VERSION above is the current release; GitHub Releases lists every build.

To fill in $ARCH from the machine rather than by hand, $Env:PROCESSOR_ARCHITECTURE reads AMD64 or ARM64:

$ARCH = if ($Env:PROCESSOR_ARCHITECTURE -eq "ARM64") { "arm64" } else { "amd64" }

Testing status

Windows binaries are built by the release pipeline but are not executed by CI, which runs on Linux only. windows/amd64 has shipped for several releases and has field use behind it; windows/arm64 is new and has never been run end to end.

The Buzz JIT is also newly enabled on Windows - it was disabled there until this release line - and its generated machine code has not executed on any Windows machine during development. If a magusfile gives a result that looks wrong, re-run with the JIT off:

$Env:BUZZ_JIT = "0"
magus run <target>

If the answer changes, that is a JIT bug rather than a magusfile bug, and it is a very useful thing to report. See Platform support.

Which archive

The _static archive above is what both architectures ship, and it is what magus self update fetches. No dynamically linked archive is published: on Windows it would link the MSYS2 mingw copies of libzstd/liblzma, which a user's machine has no reason to carry. magus run release-build:dynamic produces one from source if you want it.

Verify the download

Fetch the manifest and its signature next to the tarball:

curl.exe -fLO "https://github.com/egladman/magus/releases/download/$VERSION/SHA256SUMS"
curl.exe -fLO "https://github.com/egladman/magus/releases/download/$VERSION/SHA256SUMS.sig"

Then verify the Ed25519 signature first, and only then the checksum - checking a hash against an unverified manifest proves nothing. The exact commands are in Verify a release.

Put it on your PATH

If magus version is not found, add the install directory to your user PATH (persists across sessions):

[Environment]::SetEnvironmentVariable("Path", "$Env:USERPROFILE\bin;$Env:Path", "User")

Open a new PowerShell window afterward, then re-run magus version.

Next steps

downloadinstallwindowspowershellpath
Last updated (4f8cc295)
Earlier changes on this page (3)

Full history ↗ · Blame source ↗

Glossary

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. See targets.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. See targets.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). See operations.

Ward

A coded diagnostic that inspects a resolved op and nudges or blocks an anti-pattern before it runs. See wards.

Buzz

The language magusfiles are written in (the .buzz engine). See engines.

CI

An ordinary magusfile-defined target you compose yourself with magus\needs - magus does not hardcode its stages. Magus.RunCI treats it specially only in that it strips the rw charm, it is the anchor magus affected ci keys off, and a selected scope with no project declaring it is a load error rather than a silent no-op. See targets.

Session

One magus process's recorded facts - the targets it finished, their outcomes, and the lease it acted as - kept in a repo-scoped store every worktree shares. magus session lists them; the store prunes itself by last-fact age.

Lease

One row of the lease ledger: a piece of work an orchestrating agent handed out, with its goal, the checkpoint it was cut against, and the paths it owns or must not touch. The ledger records; the agent guard is what reads those facts back when grading a write. See doctrine.

Conventions

Admonitions

Call-outs are rendered from GitHub-style alert blockquotes and carry a colored accent per type:

Note

Context worth knowing, but not a warning.

Warning

Something that can bite you if ignored.

The types are NOTE, TIP, IMPORTANT, WARNING, and CAUTION.