Juliaup: the version manager that makes julia a multiplexer over release channels

Two things ship in one repository: an installer and a version manager

The README makes a point that is easy to skim past. The repository contains a cross-platform installer for the Julia programming language, and it also bundles a full Julia version manager called juliaup. The installer gets you a working Julia; the version manager is what lets you install specific Julia versions, be alerted when new releases appear, and select between them through a release channel abstraction. Both a command line tool and a graphical application are provided, the latter being the Juliaup GUI. The status is stated as production ready, and the repository description calls the tool a Julia installer and version manager while Cargo.toml describes the package as a Julia installer and version multiplexer, which is the more precise framing of what it does.

Channels are the abstraction, and the julia command becomes a multiplexer

What makes juliaup different from a directory of installed versions is the channel concept. A channel is a named stream of Julia releases, and the julia command on the PATH becomes a multiplexer over whatever channels and versions you have installed. The README shows what that means in practice. Once juliaup is installed, julia is on the PATH, and on Windows there is a start menu shortcut and it appears as a profile in Windows Terminal, and the VS Code extension finds the installation automatically. To move between versions, juliaup add 1.5.1 adds that specific release and it can then be launched with julia +1.5.1, while juliaup default 1.5.3 makes the plain julia command start that version, and juliaup default 1.6 points at the latest 1.6.x you have installed and tells you if a newer 1.6.x exists.

Installing on Unix is one piped shell command, and it is configurable

On Linux, Mac and FreeBSD the install is a single command in a shell.

curl -fsSL https://install.julialang.org | sh

Arguments are passed by adding them after a double dash, which is the convention for piping arguments into a shell script.

curl -fsSL https://install.julialang.org | sh -s -- <ARGS>

The documented options are --yes for a non-interactive run using all defaults, --default-channel to pick the channel such as lts, --path to install juliaup into a custom location, --add-to-path to control whether shell startup files are modified, and two self-update intervals. A fully scripted install looks like this.

curl -fsSL https://install.julialang.org | sh -s -- \
    --path "$JULIAUP_DEPOT_PATH" \
    --yes \
    --add-to-path=no \
    --background-selfupdate=0 \
    --startup-selfupdate=0

That combination is the one to use in CI, since it leaves the machine's shell configuration alone and stops both update checks.

The two self-update intervals are different on purpose

The self-update settings deserve a note because the defaults look odd side by side. --background-selfupdate takes a number of minutes and controls how often a background task checks for juliaup self-updates, defaulting to 0, which disables it. --startup-selfupdate also takes minutes and controls how often Julia startup checks for juliaup self-updates, defaulting to 1440, which is once a day. The result is that the check happens when you start Julia rather than on a timer, and the timer variant is off by default. For a shared machine or a container, that default is arguably a network call you did not ask for on every Julia launch, which is why the fully scripted example above turns both off.

Windows has four routes, and the README ranks them

The Windows story is more layered than the Unix one, and the README is candid about which is which. The Microsoft Store route is the primary one, either by installing from the store listing or from a command line.

winget install --name Julia --id 9NJNWW8PVKMN -e -s msstore

If the store is blocked, there is an MSIX App Installer based setup, downloaded as Julia.appinstaller and opened by double clicking, and the README marks this one as currently experimental with an issue thread for reporting successes and failures. If neither works, an MSI installer is available in 64-bit and 32-bit forms, but the README says this method comes with serious limitations and is generally not recommended unless nothing else works, with the example being that there is no automatic update mechanism for juliaup. The MSI install defaults to per-user without elevation, and a system-wide install is done with msiexec and the ALLUSERS=1 flag. One hard dependency is called out: juliaup requires the Windows.Web.Http API, which is present on Windows and Windows Server but not on Windows Server Core or Windows Nano Server.

OS package managers are available but the maintainers advise against them

Juliaup can be installed through several distribution channels, and the README puts an important note above all of them. It strongly recommends installing through the Windows Store or the curl command rather than through OS-specific software repositories, because the juliaup variants provided by the latter currently have drawbacks that the project hopes to lift, and in particular some of those packages build only the command line tools and not the Juliaup GUI. The listed options are brew install juliaup on Homebrew, two AUR packages on Arch Linux, one locally built and one using the binary from GitHub releases, zypper install juliaup on openSUSE Tumbleweed with root privileges, eopkg install juliaup on Solus also with root privileges, and cargo install juliaup through Rust's package manager. The cargo route matters because the project itself is written in Rust.

The Cargo manifest explains the two-binary architecture

The Cargo.toml file is worth reading because it documents a decision that is easy to trip over. The workspace has two members, the root package and juliaupgui, and there is deliberately no default-members entry, with a comment explaining that a bare cargo build, test or install should keep selecting just the root package as it did before the GUI existed, and that juliaupgui is built and tested through an explicit -p juliaupgui. The release profile enables link time optimisation and sets codegen-units to 1. The dependency list is a mix of CLI plumbing and download machinery, with clap and clap_complete for argument parsing and shell completions, including a nushell completion generator, semver for version comparison, flate2 and tar for unpacking downloads, indicatif and console for progress output, dialoguer for prompts, ctrlc and cluFlock for interruption and file locking, and env_logger with log for diagnostics. There is also a release.toml, a Cross.toml for cross-compilation, a build.rs and a versiondb/ directory.

The command set covers listing, updating and pinning

The README walks through what juliaup can do, and the set is small enough to learn in a minute. juliaup list shows all the available channels, and juliaup update installs the latest available Julia version for all of your channels, with juliaup update release narrowing that to the release channel. juliaup status reports which Julia versions are installed and which one is the default, and juliaup add takes a version to install, while juliaup default takes a version or a channel name to configure. The version specification is flexible in a useful way, since juliaup default 1.5.3 pins an exact release while juliaup default 1.6 tracks the latest 1.6.x you have and warns when a newer one is available. For CI, the README points at the julia-actions/install-juliaup GitHub Action, which exists specifically to install Juliaup in a GitHub Actions job.

Editorial conclusion

Juliaup fits a developer or a CI job that needs more than one Julia version available at once, because the channel abstraction and the julia +version syntax let a project pin its toolchain without a separate directory per release, and the installer is unattended-capable enough for CI. It is a poor fit for a locked-down environment with no outbound network, since the whole model depends on downloading Julia releases on demand, and a poor fit for a single-version install where the plain Julia installer is one step fewer. Verify first which channel you want as the default before you install, since that choice is baked into your shell startup files, and note that the installer refuses to be tidy on its own, so remove any previous Julia and undo any manual PATH edits first.

Frequently asked questions

Official sources

1. Issues
2. JuliaLang/juliaup on GitHub
3. License: MIT
4. README
5. Releases