Rez + Ayon

I’m not using OpenPype or Ayon yet but I’m browsing through the documentation in preparation for an eventual test drive. I noticed that the DCCs must be launched through the Ayon app that must be downloaded and installed locally on the desktop machines. This concept is not compatible with our current solution (Rez) and would complicate things considerably for us.

I’m starting this topic in order to start a discussion around the possibility of adding support for Rez, to talk about how we are using it and hoping others can chime in with their own experience.

Back Story

We are a university with over 250 machines running Windows (not my decision). At the beginning of the school year, the IT department ask all the teachers which software they need for their classes, they install them all on one computer, ask the teachers to test and then image that computer to all the others. Then we are stuck with that config for the rest of the year. Teachers don’t have admin rights on the machines so they cannot install new versions themselves if they wanted. They do have admin rights on their own computer only, in their office.

I didn’t like that. I like to update DCCs and plugins with point releases during the year for all the students. That’s why I installed Rez myself. I put it on the network in a place I have write access, I created a bunch of packages and I even installed Maya, Nuke, Houdini and Mari to that location on the network (installed locally on my machine, copied the folder to the network and created a rez package for them). I did the same with the Arnold plugins for Maya and Houdini and the maya-usd plugin.

The advantages of Rez

This way, I can update those applications and plugins whenever I want (which is usually within a week of a new release). Also, when you launch an application through Rez, it launches from the network but while you are working, it can copy the folder locally to the machine so the next time you (or anyone else) launch the same app, it will use the local copy.

Of course, Rez also manages the versions intelligently. When you request the latest version of Houdini and the latest version of htoa, it uses the latest two versions that are compatible together. That is the main reason for using Rez in the first place.

Rez packages can define environment variables, several different packages can add to one single environment variable (PATH, PYTHONPATH, etc.). They can define aliases to define commands to execute in the terminal (the houdini package defines the houdini alias, the hython alias, husk, mplay, etc.) so once you are inside a rez environment, you can simply type the name of the alias to launch the tool you want.

How we use it

I have created a set of Windows shortcuts in a folder accessible to all. Each shortcut contains a rez-env command and a list of packages to load. For example, the houdini shortcut has this command:

rez-env houdini-19.5 htoa-6 ocio_config_aces castors -- houdini

Specifying houdini-19.5 makes sure that this shortcut never launches Houdini 19.0 or Houdini 20.0 when it’s available. The same goes for htoa, it specifies version 6 so it can pick any version as long as it starts with 6. The ocio_config_aces packages is one I made that provides the config and sets the OCIO environment variable accordingly. And the castors package is for a project we were working on this winter. It adds a few custom HDAs to the houdini session and sets a few settings.

When a new version of Houdini or htoa becomes available, I can simply install it on the network, update the package for it and release it. The next time someone uses the shortcut, the rez-env command will resolve to the new version and launch it. I don’t even have to update the shortcut, or to tell the students about it. If I release a new version of Houdini but don’t release the version of Arnold that goes with it, the shortcut will not launch that new version. It only uses versions that are compatible together.

During the last semester, we needed to test a beta version of Arnold for Houdini. I created a new shortcut specifying the beta version and bypassing the filter (we have a rez filter that ignores beta versions by default). So when using this shortcut, students would fire up a houdini session with the beta version of Arnold and they were able to test it on any machine, and even in the render farm.


To me, it looks like Rez could do a lot of what that Ayon app does already, but in a more flexible way. There could be an ayon package that defines the environment variables it needs to send to the DCC. It could also define the aliases for the commands it has.

This way, studios could choose how they launch applications the way they want with Windows shortcuts, their custom rez launcher, or any other method. Or the Ayon app could use a list of package requests and the name of an alias to launch an app instead of a hard coded path, and inject its own package to the list.

For us, it greatly simplified the way we manage applications and plugins. I even showed it to the IT guys and they were excited how much it improved the system we had in place. I also simplifies the way I can release my own plugins to the students. So I think it would be a blocker for us if we can not launch applications through Rez.

Next year, I will create a shortcut for each application, for each project team. They can decide which version they want to use and if they want to use Arnold with Houdini or Maya, or RenderMan, and decide the version of the renderer they use. This way, each team will have a tailored made application for their needs and we will still be able to update them very easily.


And to add to this story, here is how we used it at my previous job.

I worked for RodeoFX for 5 years as Pipeline Architect and then Head of Pipeline. We built a Rez launcher that ran in the terminal and was used by all artists to launch their applications.

It allowed a supervisor to “install” rez packages (or rather rez requests) to a given context on a show, for a given app. So lets say we want to use Nuke on show xyz. The supervisor could decide that Nuke should use Nuke-13.2v<latest>, neat_video-5.4.7, and twixtor-5.<latest>. They simply run the launcher with the install agrument and lists the package requests Nuke-13.2, neat_video-5.4.7, and twixtor-5 for app nuke, for show xyz. This would save the list of requests in the DB for that show. Later, when an artist launches Nuke on that show, the launcher would retrieve the requests and send it to rez to launch the application.

The beauty part is that we could add or remove requests for specific shots. If one shot in that show needs an additional package, we could add it just for that shot. And the shot would still inherit from the show so adding a new package to the show would still add it to all shots under it.

We used that feature pretty often. It happened that a sequence of a show was done using a beta versions of a DCC, while the rest of the shots used a release version. With this system, artists never need to know which version to launch, the launcher does it for them.

This launcher is still in use to this day, with Rez.


Hey, let me point you to recently started discussion on Github about the way how Rez can be implemented:

To add to it - you can use Rez with OpenPype/AYON even now for launching your DCCs - you don’t have to configure application executables, you can use your shell scripts that will invoke Rez to do whatever magic you need to get app started. In the most cases, you can’t then use easily environments set by OpenPype/AYON to control plugins and other tools and that is one of the major caveats.

We are already implementing Rez on server side, to help us managing dependencies between addons btw.

Thanks for this nicely written summary of your Rez usage!


Just wanted to link this draft PR for a Rez integration for the Ayon Backend since it’s one of the steps of linking Rez and Ayon together. Whether it tries to solve what came up here I’m not sure but just referencing so others are aware some Rez effort seems to be put in.

1 Like

Hi All,

This might relate to a different thread. Would it be possible to use rez commands instead of Application paths to executables?. For example a command such as “rez env nuke plugins … – nuke”
that would launch Nuke with all custom packages plus the OpenPype/Ayon plugins.

Thanks for your time!

That’s definitely the goal of this particular topic (or at least what I think @flord described) - so you’re in the right place.

A little above this was mentioned by @antirotor

To add to it - you can use Rez with OpenPype/AYON even now for launching your DCCs - you don’t have to configure application executables, you can use your shell scripts that will invoke Rez to do whatever magic you need to get app started. In the most cases, you can’t then use easily environments set by OpenPype/AYON to control plugins and other tools and that is one of the major caveats.

So likely it’s already possible (in a hacky way) by doing that, but I suspect it’s highly untested.

But there’s also been mention that it makes much more sense to instead replace the “Applications” module/addon with an application launcher module of its own that uses Rez in the backend instead. However, there’s no ready to go solution for that currently.

Definitely vote at the top of this topic if this is indeed what you’re interested in, just so there’s a visual cue of interest for this.

1 Like

It is actually well tested and has been in production with some clients for a long while. it’s the main reason why we have arguments option in the application settings.

You can play around with rex command and arguments in here: ayon+settings://applications:1.0.0/applications/maya/variants/0/executables/windows

What is not supported yet is replacing the tool groups (dcc plugins for example) with a granular rez setup that you could control from the UI. We are in the middle of conversations with a client that is interested in that thoug, so I think we’ll need to make it a lot more robust very soon.