Dependencies

Dependencies are other packages your project builds against. They are declared in the [Dependencies] table of Rux.toml and managed with the rux command-line tool.

Declaring a dependency

Each key is the name you import the dependency under, and each value is an inline table:

[Dependencies]
Io = { Namespace = "Rux", Version = "^1.0.0" }
Json = { Namespace = "Acme", Package = "FastJson", Version = ">=2.0.0, <3.0.0" }
Windows = { Namespace = "Rux", Version = "0.1.0", TargetOS = ["Windows"] }
Bsd = { Path = "../Bsd", TargetOS = ["DragonFlyBSD", "FreeBSD", "NetBSD", "OpenBSD"] }

A registry dependency needs a Namespace and a Version. A path dependency needs a Path and cannot carry either. Both may set Package when the dependency's own name differs from the import name.

Both forms may set TargetOS to a non-empty allow-list. The dependency participates in builds and resolution only when the selected target OS appears in the list. Omitting it means every target. The exact supported names are Windows, Linux, MacOS, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, and Illumos; duplicates and other spellings are invalid.

An active import of a dependency that excludes the selected build target is an error. Imports removed by when #target.os are inactive and therefore allowed, so platform packages should guard their imports with the same target condition as their dependency entry.

Adding and removing

rux add writes the entry for you:

# Registry dependency, any stable version
rux add Rux/Io

# Registry dependency with a requirement
rux add Rux/Math@^0.1.0

# Local path dependency
rux add Util --path ../Util

Omitting the requirement writes *. A registry dependency needs a namespace — rux add Io alone is rejected, because the bare name does not identify a package in the registry.

Remove one with rux remove:

rux remove Json

Version requirements

A requirement is a comma-separated intersection of comparators; whitespace around them is insignificant.

Operands may be partial (^1.0, 2) or use a trailing component wildcard (1.2.*). A numeric component cannot follow a wildcard, and a prerelease or build suffix needs a complete major.minor.patch operand. Requirements reject OR expressions, hyphen ranges, space-separated comparators, more than three numeric components, and more than 32 comparators.

A prerelease is only eligible when some comparator names the same major.minor.patch and carries a prerelease operand of its own, so ^1.0.0 never selects 2.0.0-beta.1. See Versioning for how versions are ordered.

Installing and updating

Download everything the manifest declares:

rux install

Install for another supported target without changing hosts:

rux install --target windows-x86_64

Update to the latest compatible versions:

# Packages listed in Rux.toml
rux update

# Everything in the local store
rux update --global

# Resolve and update for Linux
rux update --target linux-x86_64

Both commands default to the host target. Before resolution they discard root requirements and transitive edges whose TargetOS excludes the selected target, so filtered dependencies cannot create version conflicts or downloads. Naming a package explicitly with rux install still installs that root package; only its conditional transitive edges are filtered.

Package storage

Downloaded packages live in a shared, per-user store separate from any project:

Each package occupies its own subdirectory named after the package. The store is managed by rux install and rux update and should not be edited by hand; use rux uninstall to remove entries.

Workspaces

Inside a workspace, a registry dependency that matches a member package by normalized identity resolves to that member instead of the registry. That is what lets the packages in one repository depend on each other in publishable registry form while still building entirely from the local tree.