Skip to content

Instantly share code, notes, and snippets.

@davidlatwe

davidlatwe/chat.md

Created June 9, 2022 21:35
Show Gist options
  • Save davidlatwe/045768459953e359bfc2dfb454c63da8 to your computer and use it in GitHub Desktop.
Save davidlatwe/045768459953e359bfc2dfb454c63da8 to your computer and use it in GitHub Desktop.
Download ZIP
Some flash back on Sweet and Park with Colin
Raw
chat.md

Hey Colin, sorry for the late reply. 😅

Let me start with some basic intro.

About Sweet and Park

  • Both Sweet and Park are rez command tools
  • Sweet can create/edit/manage rez suites
  • One rez suite for one project/template
  • Park connects to the production database and fetches active projects
  • Park provides tools based on hierarchy, global → project → asset → task
  • The relation between tools and hierarchy is done by rez context naming convention
  • Rez configs can be stacked in respect of the hierarchy
  • All environment variables are coming from rez packages. Except for some site foundation stuff, e.g where to find the database, license server, rez launching env, .etc. Which was handled by rezup.
  • rezup launches rez’s virtual env, from there we launch sweet or park or any other rez tools, and then our pipeline.

Hmm, so basically, at the concept level, our project suite is like your presets. But our suite doesn’t have versions. I see those presets have date embedded in their path which I think is like for versioning right?

I did try to implement that by keeping previously resolved context when a new one is being created. But I didn’t get that far.

The only thing we can inherit is the rez config. This is from Allan’s experience in Method, I got that from an old quick thread chat in Slack in 2020 if I remember correctly. They use config inheritance to affect the resolve, with, e.g. timestamp. And the inheriting is based on file system folder structure. This means at a different level of the working directory, users can have a slightly different setup. And I thought that is perfect for us, but then I left my job so never had a chance to validate that in production. 😢

Next 😊

Why Rez Suite

At first, I started adopting rez into our pipeline via our pipeline app launcher. Apps that were launched by rez were coexisting with legacy pipeline apps. And those legacy apps were a bunch of .bat (we are Windows-based) and called by subprocess, so I tried to follow that schema to stay minimum code change.

Rez suite is essentially baking requests into an executable yaml as .sh or .bat. Which I thought was perfect for me to take advantage of and easy to adopt.

When I was working on the new launcher, the Park, suite-style was carried forward.

Views of Resolved Context in Sweet

  • Tools

    Showing tools that were being resolved, and able to enable/disable them in suite.

    https://user-images.githubusercontent.com/3357009/172936657-44499764-c212-422e-94b5-a01e03a10a59.png

  • Packages

    Showing package name, version, and release status

    https://user-images.githubusercontent.com/3357009/172936834-159a42b0-a51a-451b-85df-df6a990d4415.png

  • Environ

    Listing all env vars within resolved context, and showing where it was from.

    https://user-images.githubusercontent.com/3357009/172935700-4bd1d1a5-7bae-4deb-8860-54730373fc12.gif

  • Context

    Showing the content of ResolvedContext dict

    https://user-images.githubusercontent.com/3357009/172936942-cbe2016c-580d-4d92-bbb0-bb6e26d074b1.png

  • Graph

    Showing resolved graph, just like what you would get from rez-context —graph. But this hasn’t gets implemented. Original Allzpark does have this feature, I forgot why I left this out in Park 🙂

  • Code

    Showing resolved context shellcode. The shellcode is the content of the script that spawns the context in shell. Since we are Windows-based and we use CMD, the code in the image is from BAT.

    https://user-images.githubusercontent.com/3357009/172937637-d0d38acf-f002-44ee-8bda-f973f6c2c050.png

  • Log

    Just the resolve log with fancy color highlight 🙂

    https://user-images.githubusercontent.com/3357009/172938196-c5bcfc32-7a8c-44cc-a83d-40ecc03c4e5b.png

  • Diff

    Differing between two resolved contexts. This hasn’t been implemented due to the complexity. rez-gui does have this feature, which is where I got inspired from.

About the Bake

In the chat with Allan that I mentioned above, he said that Method once was suite-based as well. But since suite is actually baking requests (tools were launched from a backed context), they found it’s quite annoying to update those contexts to adopt new versions of packages. And people who manage those setups often lack production context (not rez context, the “context” 🙂) to update packages.

But looks like you only bake them in “job”, as in Deadline jobs? Which is desirable to have a baked context. So… yeah, just telling the story that I got from Allan. 😛

Maybe, Better Not Go With Suite

In hindsight, suite is not a quite fit for this. Because it bakes requests, and to overcome that, I subclassed a live-suite, which always re-resolving requests in suite. In the end, suite only works as an entity that holds requests for each tool. It would be better if I just store them in another form, like a plain dict, a .json. And maybe I could have more time to focus on more context debug tools.

That’s it for now. Hope I have answered your question 🥂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment