installing-software

Installing Software

Rule: prefer cluster modules for system software, uv/renv for language packages, and static binaries in ~/.local/bin for user tools.

Modules first

module avail
module spider git
module spider r
module spider cuda
module load git
module load r

Important: Git may require module load git. Do not assume it is in the default PATH.

For Python projects, prefer uv and a project .venv over loading a generic Python module. Use the Python module only when you specifically need cluster-provided Python or a module-provided package.

In reusable shell scripts and Slurm scripts, load required modules explicitly rather than relying on your interactive shell state:

module purge
module load git
module load r

User binaries

Put user-installed command-line tools here:

mkdir -p ~/.local/bin ~/go/bin
export PATH="$HOME/.local/bin:$HOME/go/bin:$PATH"

Prefer statically-linked builds from GitHub releases if available. Inspect "curl to sh" install patterns prior to using those. Common per-user tools:

• uv — Python project manager (install snippet below).
• duckdb — CLI for SQL over Parquet/CSV/JSON; not module-loadable on the cluster. See accelerating Python.
• qsv — fast CSV triage; not module-loadable. Same place.
• gh — GitHub CLI.
• jq — JSON on the command line.
• ripgrep — fast recursive grep.
• croc, rclone — file transfer (see using the filesystem).

Prefer static or musl binaries

If a GitHub release offers a Linux musl build, prefer it:

x86_64-unknown-linux-musl
x86_64-musl
static-linux-amd64

Why: modern prebuilt binaries often require a newer glibc than the cluster provides. Static/musl builds avoid many GLIBC_2.xx not found errors.

Typical failure:

./tool: /lib64/libc.so.6: version `GLIBC_2.38' not found

Fix: download a musl/static build, use a module, build in Apptainer, or compile on the cluster.