Rez: A Package Manager That Resolves Environments Without Installing Into Them

The Problem Rez Solves

The audience is not the typical Python developer who wants a quick virtualenv. It is for engineers who administer software for a group, where the same package version must be available to many projects and where environment creation speed matters. The README explicitly says any type of software is supported: compiled, Python, applications, and libraries. That breadth is the core value proposition.

How Rez Resolves Environments Dynamically

The mechanism is a dependency resolver plus a command evaluator. Each package has a package.py file that declares its name, version, dependencies, and commands. The commands section defines how the package configures an environment, for example by appending to PYTHONPATH. When you run rez-env with a set of requests, the resolver tracks requirements and produces a list of resolved packages. Then it concatenates the commands from all resolved packages and evaluates them to set environment variables. This is different from a system like conda that creates a new prefix with symlinks or copies. Rez does not install anything into the environment; it only computes the environment configuration. The README shows a resolved environment listing package paths like /software/ext/python/2.6.8, which are the central repository locations. The resolver can also save resolves to a file, and re-evaluating that file later reconstructs the same environment. That reproducibility is a key feature for production pipelines.

Getting Started: Install and Bind

Installation is not a typical pip install. The README instructs you to download the source and run python3 ./install.py -v DEST_DIR, with DEST_DIR as your install location. It warns that Rez is not a normal Python package and that you should not move the installation after it is done; to change paths, re-install to a new location. It also notes that you need separate installs for different operating systems. After installation, you must create essential Rez packages that describe your system. The rez-bind tool does this for platform, arch, os, and python. For example, you run rez-bind platform, rez-bind arch, rez-bind os, and rez-bind python. The README notes that binding Python may require administrative privileges. Once bound, you can create an environment with rez-env python -- which python, and it will point to the bound Python executable in your packages directory. This workflow is straightforward but requires that you treat Rez as a system-level tool, not a project-level dependency.

The package.py Definition File

The heart of Rez is the package.py file. It is a concise Python file that defines metadata and commands. The README gives an example for the requests library: name = "requests", version = "2.8.1", authors, requires = ["python-2.7+"], and a commands() function that appends {root}/python to PYTHONPATH. The {root} token refers to the package's install location. This design means that package definitions are code, which gives flexibility but also adds a learning curve. You are not just declaring dependencies; you are writing environment configuration logic. That is a trade-off: it allows complex setups like conditionally setting variables based on the platform, but it also means that a bug in a package.py can break an environment. The README does not describe a schema for more advanced features, but the example shows the pattern. For teams that already have a build system, this file becomes another thing to maintain.

Limitations and Failure Modes

One limitation is that Rez is not a drop-in replacement for pip or conda for individual developers. It requires a central repository and a set of bound packages, which is an operational overhead. If you do not have a shared infrastructure, the benefits shrink. Another failure mode is the version range syntax. The README shows requests like "pymongo-0+<2.7" and "!java-1.8+", where the exclamation mark likely denotes an exclusion. If you are not familiar with this syntax, you can easily write a range that resolves to nothing or to an unexpected version. The README does not document the full syntax, so you must consult the docs. Also, because Rez does not install packages into environments, the environment is only as good as the central repository. If a package is missing or its commands are wrong, the environment fails at resolution time, but the error messages may be cryptic for a new user. The README does not mention a rollback mechanism, so a bad package update can affect all environments that reference it.

Comparing Rez to Virtualenv and Conda

The most direct alternative is conda, which also manages dependencies and environments but installs packages into each environment. Conda creates a separate prefix per environment and copies or hardlinks packages there. That means environment creation is slower and uses more disk space, but each environment is self-contained and can be moved or deleted independently. Rez's approach is the opposite: environments are ephemeral configurations that reference a central pool. The README explicitly contrasts this with typical package managers. For a single developer, virtualenv is another alternative, but it only handles Python and does not resolve system-level dependencies. Rez's advantage is for multi-language, multi-version scenarios where you need to combine, say, Python 2.7, a compiled library, and an application like Houdini. Conda can do that too, but it creates heavy environments. Rez's lightweight environments are better suited for high-frequency context switching, such as in a render farm where each job might need a different environment. The trade-off is that Rez requires more upfront infrastructure.

Maintenance and Upgrade Costs

Rez is under active maintenance. The repository shows a default branch of main, recent releases including 3.4.0 in May 2026, and continuous integration workflows for tests, installation, and flake8. The license is Apache-2.0, which is permissive and does not impose copyleft obligations. Upgrading Rez itself is a matter of installing a new release, but you must be careful because package definitions and the resolver behavior may change between major versions. The README does not mention a migration guide, but the release notes likely cover breaking changes. The bigger maintenance cost is the package repository: every new software version you want to use must be added as a package, either by building it with rez-build or by binding an existing system install. That is an ongoing effort. If your team already has a configuration management system, you will need to integrate Rez with it, which adds complexity. The README does not describe any built-in support for remote repositories or caching, so you need to manage the central repository on shared storage.

Editorial conclusion

Adopt Rez if you manage many interdependent software packages across a shared infrastructure, especially in studios or research groups where environments must be created quickly and reproducibly. Skip it if you need a simple per-project virtualenv or you are not prepared to install and maintain a central package repository and write package.py definitions for each tool. Before adopting, verify that your target platforms are supported, that you can run rez-bind for your system Python, and that your package dependencies can be expressed as version ranges that the resolver can handle. Rez is Apache-2.0 licensed and actively maintained with regular releases, so the main cost is the operational overhead of curating a central repository, not the license.

Frequently asked questions

Official sources

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