Skip to content

ezpz update⚓︎

Upgrade ezpz in the environment you are currently in, and optionally refresh a cached copy of utils.sh.

ezpz update

Two steps, either of which can be skipped:

  1. Reinstall the package from git into the active environment — whichever venv or conda env is on your PATH right now.
  2. Re-download utils.sh into ~/.local/share/ezpz/ (or wherever EZPZ_SHARE_DIR points).

Options⚓︎

Flag Description
--ref REF Install a specific branch, tag or SHA instead of main
--utils-only Refresh utils.sh only; leave the package alone
--package-only Upgrade the package only; leave utils.sh alone
--dry-run Print the commands without running them

Examples⚓︎

ezpz update                        # package + utils.sh
ezpz update --ref v0.29.3          # pin a release
ezpz update --utils-only           # just the shell helpers
ezpz update --dry-run              # see what would happen

Login nodes only⚓︎

ezpz update refuses to run inside a PBS or SLURM job:

$ ezpz update
Error: refusing to update inside a batch job: compute nodes have no
outbound network. Run this on a login node.

This is a guard, not a limitation. Compute nodes on Aurora, Polaris and Sunspot have no outbound route, so the download would hang for ~270 s and then leave things unconfigured — a failure that surfaces much later as CONDA_PREFIX still not set or as every ezpz_* function being undefined. One line now beats four minutes of confusion later.

--dry-run is still allowed inside a job, since it touches nothing.

A partial download never replaces a good file⚓︎

utils.sh is written to a .part file and checked with bash -n before it replaces the installed copy. A truncated download passes a naive non-empty test and then fails as "every function is undefined", which is strictly worse than a clean error — so a bad fetch leaves your working utils.sh exactly as it was.

Relationship to the one-liner⚓︎

For a throwaway shell, sourcing directly is still the shortest path and caches nothing:

source <(curl -fsSL https://ezpz.cool/utils.sh) && ezpz_setup_env

ezpz update is for the case that one-liner does not cover: upgrading the installed package in an environment you intend to keep, and pinning it to a known ref.

Note that a pip installed ezpz already ships utils.sh at ezpz/bin/utils.sh, so --utils-only is only useful if you keep a separate cached copy under EZPZ_SHARE_DIR.

See also⚓︎