Rez CLI reference

One-sentence summary: every subcommand is available both as rez <cmd> and rez-<cmd>; resolve with rez-env, build with rez-build, ship with rez-release, inspect with rez-context.

Skill scope: commands and flags. For concepts see rez-core-concepts; for resolve failures see rez-resolve-troubleshooting.

Full command list

Common flags on every subcommand: -v/--verbose (repeatable), --debug, --profile FILE.

rez-env — resolve and enter

rez-env foo bah                      # interactive subshell
rez-env foo bah -- echo '$REZ_FOO_ROOT'   # one-shot, no subshell
rez-env 'python-2.6+' 'utils-1.1+<2'      # quote requests
rez-env foo -o context.rxt            # write context, don't enter
rez-env foo -i context.rxt            # load a saved context

Key flags:

rez-build — build from source

rez-build                            # build only
rez-build --install                  # build + install to ~/packages
rez-build --clean                    # clean the build dir
rez-build -- -DMYVAR=YES             # pass args to the build system

Key flags:

Build system is auto-detected (CMakeLists.txt → cmake, etc.). A package can override it with the build_command attribute. Build systems add their own flags to rez-build -h (e.g. --build-target for cmake), and a parse_build_args.py in the package root lets you add custom flags — they arrive as __PARSE_ARG_<NAME> env vars.

The build environment is assembled from requires → build_requires (transitive) → private_build_requires → the current variant's requirements. CWD during the build is the build path, not the package root — use {root} to reach scripts in the package root.

Local install loop:

# edit code
rez-build --install
rez-env mypackage        # in a separate shell; picks up the local install

You do not need a fresh rez-env after every install if requirements did not change.

rez-release — build and deploy

rez-release -m "release message"

Releases to release_packages_path (default ~/.rez/packages/int). Release hooks (amqp, command, emailer) run around it; a ReleaseHookCancellingError from a hook cancels the release.

rez-context — inspect a resolve

rez-context                          # info about the current environment
rez-context context.rxt              # info about a saved context

rez-context --so and rez-context --which are the two cheapest answers to "what did I actually get" and "where did this binary come from".

rez-search / rez-depends / rez-test

rez-search maya                      # find packages
rez-search --validate mypackage      # validate a package definition
rez-depends python                   # who depends on python?
rez-test mypackage                   # run the package's tests

rez-search flags: -t, --type, --nl, --no-local, --validate, --paths, -f, --format. rez-depends is the reverse-dependency lookup — reach for it before grepping package.py files.

rez-config / rez-status / rez-bind / rez-pip

rez-config                           # all settings
rez-config packages_path             # one setting
rez-status                           # environment sanity
rez-bind python                      # wrap existing software as a rez package
rez-pip install requests             # pip package as rez packages

Other useful ones

rez-pkg-ignore foo-1.0.0             # hide a bad package from resolves
rez-cp / rez-mv                      # move packages between repositories
rez-bundle context.rxt out_dir       # relocatable bundle
rez-interpret '"{root}"'             # test a rex expression

Agent workflow

1. Prefer non-interactive forms — -c, --output, rez-context — over opening a subshell.
2. Scope output: rez-context --so, rez-config <setting>, rez-search <pkg> -f <template>.
3. rez-status first when something looks broken about the environment itself.
4. Use rez-depends for reverse lookups instead of broad greps.
5. Build → install → test in that order: rez-build --install, rez-env <pkg>, rez-test <pkg>.