Install it

Every platform that has an archive

One command #

macOS, Linux and the BSDs:

curl -fsSL https://raku.online/install.sh | sh

Windows, in a PowerShell window — irm and iex are PowerShell's own aliases, so the line means nothing to cmd.exe:

irm https://raw.githubusercontent.com/ash/rakupp/main/tools/install-windows.ps1 | iex

Neither needs root or an administrator. Each downloads the archive for the machine it is running on, checks it against the published SHA-256, unpacks it into a per-user prefix, asks whether you also want the engine under the second name raku, and puts its bin/ on your PATH. Then open a new terminal — a running one keeps the environment it started with.

A pipe cannot pass arguments, so options go through sh -s --: --dir installs elsewhere, --version takes a particular release, --prepend puts this Raku ahead of any other on your PATH, and --uninstall removes the prefix and every line it added. The Unix script is tools/install.sh and the Windows one is tools/install-windows.ps1 — read either before running it, which is the right habit for any curl | sh. The full option tables are in INSTALL.md.

On Windows there is a wizard as well, with the same two questions as checkboxes and an Add/Remove Programs entry, so it comes off the way any other Windows program does:

Download the Windows installer

rakupp-setup-windows-x64.exe, 64-bit, from the latest release — that link follows whichever release is current. It is not code-signed, so SmartScreen will call the publisher unknown until the file earns a reputation: More info → Run anyway. The one-liner above is a script, and no SmartScreen check applies to it.

macOS

Homebrew #

brew tap ash/rakupp
brew install rakupp

brew install --HEAD rakupp     # or: the latest main branch

Apple Silicon installs a prebuilt binary and compiles nothing; Intel builds from source. Homebrew itself needs the Xcode Command Line Tools — if brew install asks for them, run xcode-select --install first.

This and the one-liner are separate installs, and neither knows about the other: brew upgrade rakupp updates this one, rakupp upgrade updates that one. With both on your PATH, whichever comes first wins.

Later

Updating #

rakupp upgrade            # replace this binary with the latest release
rakupp upgrade --check    # what is available; install nothing

rakupp upgrade travels inside the binary, like rakupp install and rakupp doc, so it works the same on every platform and there is no script on disk to fall out of step with the engine. It replaces the prefix in place — same location, same PATH entry, same raku name if you had one — checks the download against the published SHA-256 before swapping anything, and puts the old binary back if the new one does not run. Re-running the one-liner does the same thing.

It updates an install one of the two installers made, and nothing else. A rakupp that came from somewhere else belongs to whatever put it there, and rakupp upgrade names that rather than overwriting it:

Every platform, and how it is served

Supported platforms #

Six prebuilt archives ship with every release, each self-contained and each with a .sha256 beside it on the releases page. Nothing in them needs installing — they only need unpacking. Every one is built and smoke-tested in CI on the platform it targets.

The one command is this section done for you — download, checksum, unpack, PATH. To do it by hand, unpack keeping the bin/ lib/ include/ layout together — that is what --exe links against — and put bin/ on your PATH. rakupp finds its runtime library relative to its own binary, so it works from any directory; if you copy the executable somewhere on its own, point it back with RAKUPP_HOME=<prefix>.

Anywhere else — another BSD, a Linux architecture not listed, a distribution older than the archive expects — build from source. It needs CMake and a C++17 compiler and nothing else: there are no third-party libraries to find first, which is what makes the list above short rather than a matrix. Two cases have their own route rather than an archive: NixOS, which cannot run the generic Linux binary at all (it has no global ELF interpreter), and Guix, which has a channel.

Anywhere with a C++17 compiler

From source #

There are no third-party dependencies to fetch first — CMake and a compiler is the whole list.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build                       # → build/rakupp

# install the binary and the runtime --exe links against
cmake --install build --prefix ~/.local   # → ~/.local/{bin,lib,include/rakupp}

On Windows, build from a Developer Command Prompt and pass the configuration to the build step — the Visual Studio generator is multi-config, so -DCMAKE_BUILD_TYPE alone is not enough:

cmake -S . -B build
cmake --build build --config Release       # → build\Release\rakupp.exe

Linux

GNU Guix #

The repository is also a Guix channel, contributed by @4zv4l. From a checkout:

guix build -f .guix/modules/rakupp-package.scm

Or add the channel to ~/.config/guix/channels.scm:

(channel
  (name 'rakupp)
  (url "https://github.com/ash/rakupp")
  (branch "main"))

guix pull && guix install rakupp

Linux · NixOS

Nix #

nix run github:ash/rakupp -- -e 'say 42'
nix profile install github:ash/rakupp

From a checkout, nix build produces ./result/bin/rakupp.

First run

Check that it works #

rakupp --version
rakupp -e 'say "hello, world"'
rakupp -e 'say (1..100).grep(*.is-prime).sum'      # → 1060
echo 'say 42' | rakupp
rakupp program.raku

Cold start is about two milliseconds, so one-liners and shell glue feel like any other native tool. The same program in your browser, with nothing installed, is the playground.

The command line

The options worth knowing #

Flags are position-independent and cluster like perl's, so rakupp -pi.bak -e '$_ = $_.subst("a", "b")' *.txt works as you would hope. RAKUPP_PARALLEL=1 opts into true CPU parallelism for start and worker threads. The full reference is CLI.md.

The ecosystem

Modules #

rakupp install is built into the binary: it resolves against the ecosystem index, runs the distribution's own tests and writes the standard store — the same one zef writes — so a distribution installed by either tool is picked up by use with no further setup.

rakupp install JSON::Fast          # fetch, test, install; nothing else needed first
rakupp install ./my-dist           # a checkout, or a GitHub / tarball URL
rakupp test Foo::Bar               # run a dist's own suite against the store
rakupp install --list              # what is installed, and which installer put it there

use JSON::Fast;                             # installed above
say to-json({ name => 'Ada' }, :!pretty);   # {"name":"Ada"}

A store zef already filled is the same store, and what it installed is picked up as it is. Your own files under lib/ are found too, as are -I, RAKULIB and use lib paths. A use that cannot be found, or fails to compile, is fatal — the program stops rather than carrying on without the module. Across the whole Raku ecosystem, 1,006 of 2,529 distributions pass their own install-time test suites; the guide is MODULES.md.

Back to the front page The FAQ The specification