I just saw with some interest some updates to tk-core that mention supporting Rez via descriptors. I’d love to hear about what you have planned and how that might integrate with the app launcher?
Hey Patrick! I’m not sure I’m seeing what you’re seeing. I’ve marked this to run by the team, but can you point me to whatever commit or release note or other update that you saw regarding Rez? I’m happy to find out more. Thanks!
1 Like
Ah my mistake, it’s a pull-request from a 3rd party…
1 Like
Ah yes, looks like that’s an old PR that hasn’t really seen much feedback from actual humans at Shotgun. I don’t think it’s on our roadmap to merge in that functionality any time soon.
It doesn’t look like Rudy’s made his way to the forums yet, otherwise we could have him chime in on his code himself.
As it stands, I’m afraid there’s not much else to do on this one.
1 Like
I stumbled across that exact PR and was just about to pose the same question as Patrick. We’ve been using rez to package and release our studio’s non-SGTK modules and applications for a while and I’ve been brainstorming some way fold in toolkit apps, engines, frameworks and configs as well. A rez descriptor would go a long way in making that possible, although we’d prefer not to have our own fork of tk-core to do so. Have any other studios had any success marrying toolkit + rez?
2 Likes
Hey Nico (and Patrick)!
I’ll leave it to others to comment on in-studio experience, but I’d encourage you to submit a feature request for a rez descriptor. Like I said, we don’t have plans for it currently, but maybe if there’s enough traction from clients, the product team will consider it? At any rate, it would be good to track the requests.
thanks!
1 Like
Some years ago I decided to write my own environment / module system called cpenv to help manage our studio’s software, tools, and plugins. At the time rez had little to no documentation and no windows support - that was a big factor in deciding to roll my own. Recently, I was considering switching to rez, but after having invested so much time in building cpenv and our library of modules I ended up sticking with it and refactoring it to support remote repositories, including shotgun through the use of custom entities and zip archives.
Cpenv doesn’t manage the complexities of platform specific dependencies, and does not have an exhaustive dependency resolver like rez. I love those features of rez, but it was also more than I needed to manage our mostly windows based studio. Anyways, I built a toolkit app for cpenv recently that I think, if there were a similar app for rez it would really lower the point of entry for setting up a studio with rez. Heck, it would probably make me reconsider my time and switch to rez.
The key features of the shotgun app are:
- Ability to store and distribute modules via Shotgun
- Ability to configure Environments (collections of modules) per job and per application
- Environments can be imported from another job
- Modules are localized and activated prior to launching software
You can check out the toolkit app here and cpenv here.
I would love for this sort of workflow to be built into Shotgun, but the fact that it was possible to build this on top of toolkit in a relatively short period of time was excellent. I’m not trying to advertise cpenv, only to share my own experience with building / working with a rez-like tool, and maybe my app could be decent reference if anyone goes down a similar path with rez. I can’t recommend enough building a UI to help leads and TDs manage environments for jobs.
4 Likes
Hey Dan,
could you explain what is more convenient about something like cpenv than having for example Shotgun Apps for things like Arnold etc?
Because I was considering packaging such plugins etc up into Shotgun app for out own needs.
1 Like
Hi Ricardo,
There are a few key advantages to using modules a la rez or cpenv versus shotgun apps.
-
Portability - You can create, test, and share modules without shotgun toolkit. As a developer this helps me push revisions to artists quickly. I don’t have to release a new Shotgun config for a small patch that has nothing to do with Shotgun.
-
Modularity - My studio’s environment is now built from dozens of modules, all with their own environment variables, python scripts, and binaries. Each of these is a very small, isolated chunk which I can test individually or in groups. Conversely because of the way a shotgun config is broken up, toolkit apps can have their configuration scattered across several files.
-
Ease of use - It was pretty easy to teach our cg leads how to set modules and import modules for a new project. I still do that most of the time, but it’s nice to know that if I’m sick or out of the office, they would be able to get by.
I would be remiss if I didn’t mention what I think is a huge disadvantage to using rez or cpenv though and that is SUPPORT!
Cpenv is a community of one (me 
). I of course would attempt to help anyone who used cpenv, but, I couldn’t guarantee I’d be able to offer support in a timely fashion. Contributors would be welcome though!
Rez has a thriving community with TDs and engineers throughout our industry. This means that potentially many other people will have had issues you might encounter and be able to help you. However, like any open source project the amount of time they have to spend working with you is subject to how much free time / sanctioned work time they have. Problems also will be prioritized by their own interests (whether that be issues that align with work or something else).
Shotgun on the other hand has a fantastic and dedicated support staff.
5 Likes
Thanks Dan!
very helpfull!
1 Like
Cough Cough
There is an open PR to allow writing your own custom descriptors.
I need more people to jump on the bandwagon with me to help bring that feature up to the forefront.
Take a look and let me know what you think.
2 Likes
Hi all! Wanted to chime in with a couple thoughts:
-
@Dan_Bradham: thanks so much for sharing your
tk-cpenvapp with us! It’s awesome. I’ve added it to our Community Shared Integrations page.- One note: you might want to consider changing the name of your app to match the naming convention we use for our own tools: Typically, engine names are of the form
tk-<DCC>liketk-mayaortk-nuke, whereas app names are of the formtk-<engine|multi>-<app-name>. So, if your app runs across all engines, you’d call ittk-multi-cpenv. If it runs only in a specific engine, say thetk-shotgunengine, it’d be calledtk-shotgun-cpenv. Having said that, as you can see on the above link, people are all over the place with their app naming, so it’s totally your call. - And thanks for the kind words about our support team. We try!
- One note: you might want to consider changing the name of your app to match the naming convention we use for our own tools: Typically, engine names are of the form
-
And @Ahuge et al.: Alex, thanks for all the work you’ve put into your PR! And I love the campaigning =). If this is a feature people are interested in, I’d suggest requesting it on our roadmap page – that’s where our product team organizes community feedback/interest in specific requests.
And as usual, thanks to all of you for your active engagement with Shotgun. It’s so heartening to see, and you truly make our products better with your contributions and your feedback. It means a great deal to us. We’ve really got the best users!
1 Like
Thanks @tannaz, I’ll consider renaming the app with the next release.
2 Likes
I am coming to the conversation late. I, too, have rolled my own packaging tools, as Dan described. That was a long time ago. I would no longer be interested in doing it again or maintaining it. However, in doing so we used SG and some Custom Non-Project entities to document packages and link them to software, project, and pipeline step entities to manage availability and usage.
More recently, in a new role, I was exposed to Rez and was delighted. Rez can be strapped to SG and a Toolkit hook to capture environment configuration as it relates to Published Files and versions. With some fancy footwork with Action Menu item dialogs, the limits are endless. I would love to see SG and Toolkit do Rez integration. Furthermore, I would also like to see the same work feed cloud rendering with AWS and Google. The environments needs to be documented as files are published, and this seems like a necessary thing to pivot from on-premise rendering to cloud rendering and compute.
You got my vote!!!
2 Likes
Hey folks on this thread—you may be interested in @Sreenathan_Nair post over here as well:
2 Likes