interfacing users with rez

[seba...@risefx.com]

Hey,

I am aware that rez is not intended to be a configuration management solution (for a project, sequence, shot ect.) but rather a environment configuration tool. But I was wondering what kind of systems people have build to get an artist into a specific configuration/environment for a project. The place I work at is traditionally doing all tool setup from inside an already open DCC application providing special UIs to select a show, shot etc. Rez on the other hand is build to run before an app starts to setup env vars for the app to pick up. So, do you make artists enter a terminal type "maya" and then type the show name, and shot name? Or do you have a gui to launch be it custom or somthing like shotgun?

Thanks for the insights!

Cheers

Sebastian

[Alexandra Lefève-Gourmelon]

Hi Sebastian,

Allan has developped a solution for this in his soma branch, which has not yet been integrated in resources2 branch, I think.

Here, we are using 2 other solutions:

- The first is an inhouse development which is something very similar to soma that we had started before soma was avaliable, with some config files per project. The user set his project in the shell, and then all softs can be launched through aliases such as maya, with the right versions of each package.

- The second is to create special packages for each prod (and so no development is needed ;) ). The aliases are redefined inside these packages and so you just enter rez env <myProd>Maya, and then you use the aliases defined in this package.

HTH,

Alex

--
You received this message because you are subscribed to the Google Groups "rez-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.
To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

--

Alexandra Lefève-Gourmelon Pipeline TD g...@mikrosimage.eu Mikros Image Digital Post-Production for Video and Film  www.mikrosimage.eu

[seba...@risefx.com]

Hey,

thank you for the hints! Did you ever encounter the need to define package variations on a sequence/shot bases?

Cheers

Sebastian

[Alexandra Lefève-Gourmelon]

We have anticipated this case, but we don't have encounter the need for it yet.

But no big project has been run through rez from start to end yet, which explains this.

[allan.johns]

Hi Sebastian,

So, you are correct, Rez makes a clear distinction between configuration management and package management.

Rez was first designed with the workflow in mind that artists would run some external 'setshot' type command, which would then place them into a show/shot/sequence/task etc, at which point the environment(s) relevant to that area of production would be configured via rez. However, the approach you mention (switching shots from within a DCC) is not at all mutually exclusive to using rez. Rez has a rich API, and you could use it, for example, to configure the new shot you want to 'switch' to in your DCC, and then get the environ dict from that new resolve, and apply those changes to your current session appropriately. Of course, what you can do when already within a DCC is limited - for example, a different shot might require a different version of package(s) that you might not be able to switch to - a compiled maya plugin that won't load/unload properly for example, or indeed a different version of the host app itself! But the code to create a new resolve and get its environment variables is trivial:

>>> r = ResolvedContext(["maya-2014", "utils-1.2+<2", "vray-3.0.22103"])
>>> new_environ = r.get_environ()

IMO the best approach to managing software in a vfx environment is to use some configuration system in combination with Rez. The configuration system would allow you to configure many things - LUT lookups, licence servers, the list goes on - but part of this configuration info is used to configure (a) what environments you want available in an area of production and (b) what versions of packages are within these environments. Such a configuration system should allow you to provide defaults and overrides - for example you may want to define a 'nuke' environment that all shows will have in common, yet be able to override the packages used in this environment for a particular show, or even shot. The package configuration settings are used to drive Rez - Rez is the underlying tool that creates the resulting environments at runtime. A lot of work has been done recently in making Rez much faster so that it's better at resolving these environments.

The 'soma' project that Alexandra mentions is a stab at providing this kind of system, however it only provides a configuration system for Rez itself. I think the downside to this is that it is simply inevitable that production would like to see a single interface for configuring productions, and a project that does this - a general configuration management system really - is certainly outside the scope of the Rez project. This is always what has stopped me from adding this functionality to Rez in the past - that configuration as a whole encompasses Rez, but other things as well. It would be a great project to work on, but one I've never actually had time to do (not in the open source arena anyway).

Another approach is to use 'suites' to manage your software, and for small to mid-size operations I think this could be a good approach (it's what we're doing at Method but we are outgrowing this imo). A big upside to this take is that you don't get the hit of runtime resolves - suites contain pre-resolved environments, so tools launch quickly. A downside is that extra maintenance is required - in order for production to consume new packages, contexts and the suites containing them need to be updated. Also, as stated earlier, Rez is much better now at runtime resolves, so the speed benefit to suites is reduced somewhat (it has a caching system that often gives the same tool boot times).

So, to more directly answer your questions:

1) So, do you make artists enter a terminal type "maya" and then type the show name, and shot name? Or do you have a gui to launch be it custom or somthing like shotgun?

Generally systems I have worked on are based on the idea that there's some "setshot" type command, that sets the user into a shot in a given show. Once in that environment, there are tools available that will launch the user into the appropriate environment (or 'context' in rez-speak). To the artist it looks like there is one big environment available that provides maya, nuke and a multitude of other tools - in actuality, these are wrappers created by rez, that will boot the user into a separate environment and then run the tool. In 'suites' this is done via wrapper scripts that Rez creates on disk (inside the suite); in Soma, it's done via shell aliases that Rez creates also.

A gui-based launcher is entirely possible and in fact you can see that in action in Rez itself, using the 'rez-gui' tool. This tool is not designed to be a general launcher, but it does allow you to browse packages, create contexts, inspect their contents, and launch tools from the resulting environment.

2) Did you ever encounter the need to define package variations on a sequence/shot bases?

Theoretically you could do this but I have not encountered the need either. I have the impression this would be more trouble that it's worth - it's hard enough keeping track of package releases in a central location, let alone at the sequence and shot level also. I can see the need at the show level, although this should be avoided where possible.

Hth,
A

[Alexandra Lefève-Gourmelon]

I just realizaed I had misread the question about shot variations.

Actualy, we don't need this kind of thing. The configuration can be at sequence or shot level, but the packages are independent from the show.

Cheers,

Alex

--
You received this message because you are subscribed to the Google Groups "rez-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.
To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

[seba...@risefx.com]

Am Dienstag, 19. Mai 2015 02:23:12 UTC+2 schrieb allan.johns:

Hi Sebastian,

So, you are correct, Rez makes a clear distinction between configuration management and package management.

Rez was first designed with the workflow in mind that artists would run some external 'setshot' type command, which would then place them into a show/shot/sequence/task etc, at which point the environment(s) relevant to that area of production would be configured via rez. However, the approach you mention (switching shots from within a DCC) is not at all mutually exclusive to using rez. Rez has a rich API, and you could use it, for example, to configure the new shot you want to 'switch' to in your DCC, and then get the environ dict from that new resolve, and apply those changes to your current session appropriately. Of course, what you can do when already within a DCC is limited - for example, a different shot might require a different version of package(s) that you might not be able to switch to - a compiled maya plugin that won't load/unload properly for example, or indeed a different version of the host app itself! But the code to create a new resolve and get its environment variables is trivial:

>>> r = ResolvedContext(["maya-2014", "utils-1.2+<2", "vray-3.0.22103"])
>>> new_environ = r.get_environ()

I see your point. And I think a limited amount of runtime customization could be achieved. Of course the basic problem with this approach is, that Maya, Nuke and Houdini do some kind of auto-discovery of gizmos, plugins, digital assets or special files like menu.py, userSetup.py or 123.py and they only get picked up if they are in a special "PATH" environment variable at startup. Some apps like maya allow limited configuration via Pythons own "sitecustomize.py" (which would be a good place for rez, I think), but for example, Nuke lost that "feature" between some "minor" version and it never made it back in.
 

IMO the best approach to managing software in a vfx environment is to use some configuration system in combination with Rez. The configuration system would allow you to configure many things - LUT lookups, licence servers, the list goes on - but part of this configuration info is used to configure (a) what environments you want available in an area of production and (b) what versions of packages are within these environments. Such a configuration system should allow you to provide defaults and overrides - for example you may want to define a 'nuke' environment that all shows will have in common, yet be able to override the packages used in this environment for a particular show, or even shot. The package configuration settings are used to drive Rez - Rez is the underlying tool that creates the resulting environments at runtime. A lot of work has been done recently in making Rez much faster so that it's better at resolving these environments.

The 'soma' project that Alexandra mentions is a stab at providing this kind of system, however it only provides a configuration system for Rez itself. I think the downside to this is that it is simply inevitable that production would like to see a single interface for configuring productions, and a project that does this - a general configuration management system really - is certainly outside the scope of the Rez project. This is always what has stopped me from adding this functionality to Rez in the past - that configuration as a whole encompasses Rez, but other things as well. It would be a great project to work on, but one I've never actually had time to do (not in the open source arena anyway).

Yes, this is a totally different can of worms, I know :D
 

Another approach is to use 'suites' to manage your software, and for small to mid-size operations I think this could be a good approach (it's what we're doing at Method but we are outgrowing this imo). A big upside to this take is that you don't get the hit of runtime resolves - suites contain pre-resolved environments, so tools launch quickly. A downside is that extra maintenance is required - in order for production to consume new packages, contexts and the suites containing them need to be updated. Also, as stated earlier, Rez is much better now at runtime resolves, so the speed benefit to suites is reduced somewhat (it has a caching system that often gives the same tool boot times).

Thanks for the hint, suits may just be enough for the size we are running here.
 

So, to more directly answer your questions:

1) So, do you make artists enter a terminal type "maya" and then type the show name, and shot name? Or do you have a gui to launch be it custom or somthing like shotgun?

Generally systems I have worked on are based on the idea that there's some "setshot" type command, that sets the user into a shot in a given show. Once in that environment, there are tools available that will launch the user into the appropriate environment (or 'context' in rez-speak). To the artist it looks like there is one big environment available that provides maya, nuke and a multitude of other tools - in actuality, these are wrappers created by rez, that will boot the user into a separate environment and then run the tool. In 'suites' this is done via wrapper scripts that Rez creates on disk (inside the suite); in Soma, it's done via shell aliases that Rez creates also.

A gui-based launcher is entirely possible and in fact you can see that in action in Rez itself, using the 'rez-gui' tool. This tool is not designed to be a general launcher, but it does allow you to browse packages, create contexts, inspect their contents, and launch tools from the resulting environment.

2) Did you ever encounter the need to define package variations on a sequence/shot bases?

Theoretically you could do this but I have not encountered the need either. I have the impression this would be more trouble that it's worth - it's hard enough keeping track of package releases in a central location, let alone at the sequence and shot level also. I can see the need at the show level, although this should be avoided where possible.

Thank you very much for the detailed explanation!