Julia juliaup¶

ID: juliaup
Home page: https://github.com/JuliaLang/juliaup
Version requirement: >= 1.21
Platforms: 🐧 Linux · 🍎 macOS · 🪟 Windows
Operations: installed · outdated · search · install · upgrade · upgrade_all · remove · cleanup
purl types: pkg:juliaup
CLI name: juliaup
Issues and PRs: 📦 manager: juliaup
Source: meta_package_manager/managers/juliaup.toml

juliaup is the Julia version manager (https://github.com/JuliaLang/juliaup).

A package is a channel, and there is nothing else it could be. Every verb juliaup exposes takes exactly one channel token: add, remove, update, default, link and override set all share that one argument shape. Concrete installed versions are not addressable at all, living only in an internal deduplication table no command accepts a key from, so the choice between naming a channel and naming a version never arises. 1.10.11 is itself a channel name, exactly as release is.

Several channels can resolve to one concrete version, so 1.11, rc and release may all report the same version string. That is three distinct addressable packages sharing a version, not a duplicate to collapse.

The Version column is not always a version. A channel linked to a local Julia renders as Linked to `/path` and an alias as Alias to `1.11` , so the parsers require the version to start with a digit. Those rows are skipped, which is right: neither has a version for mpm to report.

Note

The patterns match spaces and tabs explicitly rather than using \s, which also matches newlines. mpm feeds these one line at a time so the distinction is currently moot, but a whitespace class that can cross a line lets the separator rule become a package id and the following row’s channel become its version, which is a silent and very confusing failure.

Caution

outdated answers offline and instantly, from a versions database on disk rather than from the network, so its freshness is whatever the last add, update or julia launch left behind. On a juliaup that has done none of those it compares against a copy compiled into the binary. No non-mutating command refreshes it, which is also why no sync is declared: the only things that refresh the database are the mutating operations themselves.

Note

Unlike its peers in this family, juliaup never updates itself as a side effect: update touches only channels, and self-update lives in a separate self update command whose behavior depends on which cargo feature the distributor built with. Naming a channel genuinely restricts the run to it.

No escalation: juliaup installs under $JULIAUP_DEPOT_PATH/juliaup, falling back to ~/.julia/juliaup, and its source carries no privileged path at all.

What `mpm` adds to `juliaup`¶

Through mpm, juliaup gains --exact and --extended search, to narrow to exact names or match descriptions.

Bigger still, mpm reaches across every manager at once: mpm installed and mpm outdated cover juliaup alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your `juliaup` commands, in `mpm`¶

You already know juliaup: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…	With `juliaup`	With `mpm`
List what’s installed	`juliaup status`	`mpm --juliaup installed`
List outdated packages	`juliaup status`	`mpm --juliaup outdated`
Search for a package	`juliaup list`	`mpm --juliaup search list`
Install a package	`juliaup add <package_id>`	`mpm install pkg:juliaup/<package_id>`
Upgrade one package	`juliaup update <package_id>`	`mpm --juliaup upgrade <package_id>`
Upgrade everything	`juliaup update`	`mpm --juliaup upgrade --all`
Remove a package	`juliaup remove <package_id>`	`mpm remove pkg:juliaup/<package_id>`

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations¶

Operation	Supported	Notes
`installed`	✓
`outdated`	✓
`orphans`
`search`	✓	exact and extended search backfilled by `mpm`
`install`	✓
`upgrade`	✓
`upgrade_all`	✓
`remove`	✓
`sync`
`cleanup`	✓	`--orphans` runs the system-wide orphan sweep
`doctor`

Selecting and configuring `juliaup`¶

Deselect juliaup for a single run with --no-juliaup, or persist the choice in your configuration:

[mpm]
juliaup = false

Keep it enabled but tune how mpm drives it with a per-manager override:

[mpm.managers.juliaup]
timeout = 900

mpm config-template juliaup prints every overridable attribute as a ready-to-paste block.

Recipes¶

A few jobs you would otherwise script around juliaup, one mpm command each:

Snapshot and clone a machine: mpm --juliaup dump juliaup.toml, then mpm restore juliaup.toml on the next one.
Export a compliance SBOM: mpm --juliaup sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation¶

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

None of its operations needs root.

See privilege escalation for the full policy.

Cooldown¶

State of Julia juliaup’s release-age gating, from the cooldown support table:

Status: ❌ None

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

Registry: Julia release channels
Retraction: None published: channels resolve through a versions database juliaup distributes, which offers no yank or unlist entry; withdrawing a release means the Julia release team dropping it from that database
Publish date: ❌ the database names versions and their download artifacts, carrying no publication date for a release-age gate to read

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --allow-unsupported-managers opts back in.

Version probe¶

The version is probed by running:

$ juliaup --version
Juliaup 1.21.0

and extracted with:

r"^Juliaup[ \t]+(?P<version>\S+)$"

Reference traces¶

Raw native outputs captured in the bundled definition: the reference mpm’s parsers were written against. If you know Julia juliaup well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ juliaup status
 Default  Channel       Version                                                        Update
----------------------------------------------------------------------------------------------
          1.6           1.6.7+0.x64.apple.darwin14
          1.9           1.9.4+0.aarch64.apple.darwin14
          1.10          1.10.11+0.aarch64.apple.darwin14
          1.11          1.11.9+0.aarch64.apple.darwin14
          1.12          1.12.6+0.aarch64.apple.darwin14
          1.13          1.13.0-rc1+0.aarch64.apple.darwin14
          1.13-nightly  1.13.0-rc1.105
          nightly       1.14.0-DEV.2820
          pr62430       1.14.0-DEV.2741 https://github.com/JuliaLang/julia/pull/62430

Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --juliaup installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog¶

7.7.0.dev0 (unreleased)
- Add the Julia juliaup version manager with installed, outdated, search, install, upgrade, remove and cleanup support, shipped as a bundled definition. Channels are the packages, since every juliaup verb takes one channel token and concrete versions are not addressable. It declares no sync: only the mutating operations refresh its versions database, so outdated answers offline from whatever they last left behind.