Application Launch - Questions RE Launch Versions

Pipeline Integrations
1

Hi

I’m new to SGTK and starting out by replacing our custom app launcher with the Shotgun Desktop.

The first task on my list is to replicate the environment variable process we have in place, but inside SGTK. Which leads me to the following:

  1. I have been controlling software versions from within the Software page within the SG web interface (all good there).

  2. I’ve made tweaks to the before_app_launch.py hook and have had success configuring custom variables prior to app launch.

So far so good. But now I’m wanting to add some finer grained control:

  1. Within before_app_launch, how do I configure the launcher to return a version of software being launched? Right now the ‘version’ var returns ‘None’.

  2. What is considered best practice for managing plugin versions? We use Redshift and often run 3 versions of the software in our env (1 prod, 1 beta, 1 testing). As an example, I would expect to create 3 Houdini versions within the launcher, with each pointing to a different version of RS. How do I control the versions for RS in such a workflow?

  3. In line with the above point, what is considered best practice for wrapping custom tools (i’m talking about tools that sit outside the SGTK environment; like hair plugins etc) into a version managed (or at least, packaged) way when using SG Desktop?

Thanks, clinton.

2 Likes
2

Hi Clinton,

When you setup software in Software Page, do you input version?

I did a test with the latest version. I could get version.

I would leave other questions to other experts. :slight_smile:

Loney

1 Like
3

Hi Loney

Thanks for your reply. YES, when I add data to the ‘Versions’ field within Shotgun I can see that value in the launch environment; great!

However, I assumed it might have been comma delimited etc, but it only takes a string (I realise I can encode a string with my own delimeters and parse it inside the launch env).

[EDIT: I’ve since chosen to populate the ‘versions’ field with an encoded string which is then parsed into a dictionary of key/value pairs. While not a perfect solution it covers what I need for the time being. I’m still keen to hear best practices with such things regardless].

So this perhaps links back to my earlier questions; what is best practice for defining an arbitrary list of plugin versions?

Thanks again, this is some progress all the same!

clinton

4

Hi Clinton,

I will ask if somebody in team can help to answer.

Thanks

Loney

8

Hi!
I think that ideally you would probably be able to configure your plugin list on the Software entity itself in a custom field and then get that information in the before launch hook. Unfortunately, Toolkit currently doesn’t communicate the software entity id back to the hook, so you can’t retrieve that custom field.

With that being said, you can store custom settings under the launch app in the environment yml file. You could introduce a setting that would enumerate the list of plugins for all dccs and their versions. From the hook you would simply have to read the settings and get the right plugin list.

How does that sound?

JF

1 Like
9

Hi JF

Thanks for the suggestions. Adjusting a YML for configuring the plugins sounds like the way to go as we can wrap the updates into git.

Right now though, my knowledge of getting such a thing to work with SGTK is close to nil, so a few pointers or pseudo code would be really appreciated eg, an example entry in the launchapp.yml and before_app_launch.py would be great.

Thanks again.

10

Hi Clinton!

The Toolkit API’s App class has a get_setting() method that allows you to get the value of a setting from your environment configuration (config/env/*). In the Default Config, the settings for tk-multi-launchapp live in config/env/includes/settings/tk-multi-launchapp.yml and are included into the various environments where the Launcher is defined. (More on includes here if you’re not familiar.)

So, you could do something like this (my specific example is junk, but it’ll give you an idea of how to get to setting values):

In config/env/includes/settings/tk-multilaunchapp.yml, modify the relevant blocks to add a setting called say, plugin_versions:

# auto discover DCCs for launch
settings.tk-multi-launchapp:
  use_software_entity: true
  hook_before_register_command: "{config}/tk-multi-launchapp/before_register_command.py"
  hook_before_app_launch: "{config}/tk-multi-launchapp/before_app_launch.py"
  location: "@apps.tk-multi-launchapp.location"
  plugin_versions: "{'Houdini17.5':['prod', 'beta', 'testing'], 'Houdini18':['prod', 'beta', 'testing']}"

Next, in your taken-over before_app_launch hook, you’ll use get_settings() to get the value of your plugin_versions setting. Since we’re in an app hook, the hook’s parent is the app, so:

plugin_versions = self.parent.get_setting(`plugin_versions`)

This will actually give you the the setting value as a string. To convert it to actual python, so you can treat it as a dict, you can use the ast.literal_eval() method. So that looks like:

import ast
plugin_versions = ast.literal_eval(self.parent.get_setting(`plugin_versions`)

From there, you’ll have a working dictionary from which you can get your plugin versions.

Hope that helps! Let us know if you have any other questions.

5 Likes
11

Hi Tannaz

This is an awesome response and exactly the kind of guidance I was looking for. I can see how this will benefit some of the other areas I was starting to explore and understand.

Thanks so much!

3 Likes
12

Thanks for the kind words! Glad it was helpful! :blush:

Good luck and let us know if you get stuck along the way!

1 Like
13

Hello!

Just wanted to let you know that with v0.11.2 of tk-multi-launchapp, we’ve added a bunch of features around what gets passed to the app’s hooks. Full details are in the linked release notes.

2 Likes
14

Thanks so much for the heads up, that’s awesome. I’ll be sure to take a look at the release notes.

1 Like