Rez: a package manager that configures environments instead of installing into them

The problem Rez solves: hundreds of package versions, one shared repository

Most package managers copy dependencies into each environment. If you need Python 2.6 for one tool and Python 2.7 for another, you pay for two copies, and every new environment pays again. Rez inverts that. According to the README, all package versions are installed into a central repository, and standalone environments only reference those existing packages. The README describes the result as lightweight environments that are "very fast to create, often taking just a few seconds to configure despite containing hundreds of packages".

That design targets a specific audience: teams that ship or run compiled applications, DCC tools, libraries and Python modules side by side, and that need a given combination to be reproducible later. A package in Rez is not only a directory of files. It carries a definition file, package.py, that declares its dependencies and its commands, so the environment is assembled from metadata rather than from a lockfile of installed artifacts. The README states that any type of software package is supported: compiled, python, applications and libraries.

The trade-off is visible immediately. Rez assumes you have a repository and a reason to keep many versions of the same thing alive at once. A single web service with one requirements.txt gets nothing from that machinery.

How a resolve works: package.py, requirements and a concatenated command set

The unit of work in Rez is the package request. The README's example is a single definition file for the requests module: it declares name, version, authors, a requires list containing "python-2.7+", and a commands() function that appends "{root}/python" to PYTHONPATH. That function is the mechanism that configures the environment: when the package is used, its commands run against the environment being built.

When an environment is created through the rez API or the rez-env tool, a dependency resolution algorithm tracks package requirements and resolves them to a list of needed packages. The commands from all of those packages are then concatenated and evaluated, which produces the configured environment. According to the README, resolves can be saved to file, and when re-evaluated later they reconstruct the same environment. That saved resolve is the reproducibility story: the resolution decision is captured, not just the resulting shell.

The README's example output shows what a resolve looks like in practice. Requesting requests-2.2+, python-2.6 and 'pymongo-0+<2.7' prints the requested packages, then the resolved packages with their install paths, including implicit entries such as platform-linux and arch-x86_64. Those implicit packages come from the binding step covered below, and they are why a resolve is portable across machines only if the same platform and arch packages exist on both.

Installing Rez and running your first rez-env

The README requires Python 3.8+ and gives the source install as the supported path. Download the source, then from the source directory run install.py with a destination directory. The README notes that the installer prints a message at the end explaining how to use Rez, that Rez is not a normal Python package so you do not typically install it with pip or setup.py, and that you should not move the installation afterwards: re-install to change the path. Installs for multiple operating systems are separate installs.

python3 ./install.py -v DEST_DIR

After that, the README says you need essential Rez packages, and points at the rez-bind tool, which creates Rez packages based on software already installed on your system. The README's example binds platform, arch, os and python, and notes that binding Python may require administrative privileges.

rez-bind platform
rez-bind arch
rez-bind os
rez-bind python

With those bound, the first real use is a shell whose Python comes from the repository rather than from your PATH. The README's example runs rez-env python with the command which python, and the output path is inside the bound package, under platform-linux, arch-x86_64 and an os directory.

rez-env python -- which python

For a non-interactive check, the README shows the same idea with a tool: rez-env houdini-12.5+ -- hescape -h runs hescape inside a resolved environment and prints its usage message. The API path is also documented, using ResolvedContext with a list of requests and execute_shell to run a command inside the resolve.

Where Rez gets in the way: install layout, platform binding and definition files

The install model is the first constraint. Because Rez is not installed as a normal Python package and the install directory must not be moved, you cannot relocate it the way you would move a virtualenv. The README's instruction is to re-install instead. That is a real operational cost for anyone used to treating tooling as a disposable directory.

The second constraint is that a resolve depends on packages that describe the machine. The README's first-use path only works after rez-bind has created platform, arch and os packages, and binding Python may need administrative privileges. If those bindings are missing or differ between machines, the same request can resolve differently. The README's example output makes this explicit by listing platform-linux and arch-x86_64 alongside the requested packages.

The third constraint is authoring. Every package needs a package.py with its dependencies and a commands() function that mutates environment variables. The README's requests example is short, but it is still code you write and maintain, and its correctness determines whether the environment behaves. There is no path in the README for a package that only needs to be present on disk without configuring anything, and the README does not document rollback of a bad resolve.

Rez is the wrong tool when the answer is one environment per project. If your dependencies fit in a single environment that you rebuild rather than resolve, the central repository and the command evaluation add work without returning reproducibility you did not already have.

Rez compared with virtualenv and conda: reference versus copy

The README contrasts Rez with typical package managers directly, with diagrams captioned "Typical package managers install packages into an environment" and "Rez installs packages once, and configures environments dynamically". That is the whole difference in approach. virtualenv and conda materialize a directory tree per environment; the environment is the artifact, and its identity is the set of files inside it. Rez keeps the artifact in one repository and treats the environment as a resolution result plus a set of command evaluations.

The practical consequences follow from that split. Copying a conda environment means copying files, and disk usage scales with the number of environments. In Rez, disk usage scales with the number of package versions, and environments are cheap because they point at those versions. On the other side, a copied environment is self-contained: it works even if the package cache is gone. A Rez environment is not, because it references the repository, and it depends on the platform, arch and os packages that describe the machine it was resolved on.

The versioning surface also differs. conda solves version constraints against channels; Rez solves them against requirements declared in package.py files, with syntax like "python-2.7+" and "pymongo-0+<2.7" shown in the README, and can save the result to a file for later re-evaluation. If your problem is reproducing a resolution decision, Rez models it. If your problem is shipping an application with its dependencies, a copied environment or a container is the more direct answer.

Maintenance, releases and what Apache-2.0 means for a studio deploy

The repository is not archived, and the last push was on 2026-05-31, which is also the date of the 3.4.0 release. Before that, 3.3.0 was released on 2025-10-17 and 3.2.1 on 2024-10-27. The spacing between those three releases is uneven, with roughly seven months between 3.2.1 and 3.3.0 and roughly seven months again to 3.4.0, so upgrade planning should assume a cadence measured in months rather than weeks. The CHANGELOG.md, RELEASE.md and INSTALL.md files at the repository root are where the project keeps the details the README does not carry.

The repository layout shows the usual maintenance apparatus: a tests directory and tox.ini, a mypy configuration in pyproject.toml that targets Python 3.8 and checks src/rez and src/rezplugins while excluding vendored and test code, ruff.toml, and GitHub Actions workflows referenced from the README for tests, installation and flake8. The pyproject.toml also sets disallow_untyped_defs for the version modules specifically, which suggests the version handling is the part held to a stricter standard.

Licensing is Apache-2.0, declared in the LICENSE file and in the SPDX header of setup.py. That is a permissive licence with an explicit patent grant, and it is the same licence used by many studio-side tools, so redistribution inside a company is normally straightforward. This is not legal advice; if you redistribute Rez or a modified build outside your organisation, read the LICENSE and NOTICE files at the repository root, because Apache-2.0 carries notice obligations that a permissive label does not remove.

Editorial conclusion

Adopt Rez if you maintain a shared software repository for a studio or a long-lived pipeline and need to reproduce the same resolved environment months later from a saved resolve. Do not adopt it as a drop-in replacement for pip or conda in a single-application project: the README states plainly that Rez is not a normal Python package and that you should not install it with pip or setup.py, and the install directory cannot be moved after the fact. Before committing, verify that your packages can be expressed as package.py definitions with a commands() function, and that you are willing to re-run install.py per operating system, because the README states that multi-OS installs are separate installs.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes