Before app launch hook - Supply **kwargs

Pipeline Integrations
,
1

Hey everyone,

I am using a custom hook_before_app_launch for the tk-multi-launchapp to setup my environments. The execute function of the BeforeAppLaunch class has a **kwars argument in its function description.

class BeforeAppLaunch(tank.Hook):
    def execute(self, app_path, app_args, version, engine_name, **kwargs):

I would like to supply some custom keyword argument to this function by defining it somewhere in env\includes\settings\tk-multi-launchapp.yml (of my tk-config-default2).
Is that possible? If not how can I supply arguments otherwise?

For background: I want to create 2 houdini starter (same houdini version), one should load arnold, the other renderman. Right now I am having a hard time identifying which starter was executed as I only have the above arguments available in the execute function.
If the above question with the **kwargs is not solvable, can I somehow retrieve the tk-desktop name of the menu item that was clicked in the BeforeAppLaunch hook to perform my logic?

2

One way you could do this is to name your launcher “Houdini with Arnold” and then you should be able to search the launcher name you are provided in the hook?

However I would suggest you look at a package manager like tk-cpenv or rez for this because that makes things much easier.

1 Like
3

Hey @Ricardo_Musch thanks for you answer!

Do you know by any chance how I would get the name of my launcher in the BeforeAppLaunch hook?
As I wrote above it is not clear to me how to retrieve this from this function declaration:

class BeforeAppLaunch(tank.Hook):
    def execute(self, app_path, app_args, version, engine_name, **kwargs):

And I would love to try rez. Never started it tough, because I felt like it’s quite an entry barrier. Any good resources on how to set it up in combination with shorgrid?

Thanks :slight_smile:

4

I use tk-cpenv which I find to play nicer with SG out of the box since it has a gui app.

Box are very similar in how they work:

You have a folder and a yaml file.
The yaml file describes the package, name, version, author, email and variables.
You then include the whole arnold plugin/install in that package, name it htoa (houdini2arnold?), give it the version of that arnold plugin, add the variables in the yaml file, i.e.

name: htoa
version: 3.3.1
author: Ricardo Musch
email: ricardo@domain.com
environment:
    HOUDINI_PATH:
        append: "$MODULE/htoa"
    ARNOLD_LICENSE_SERVER: license.mystudio.com

etc…

Depending on what you tell the package manager it will append or replace the environment variable.

So if you have multiple plugin packages for Houdini (or settings etc) you can run a virtual environment and enable htoa and several other plugins and merge the environments.

Have a look at tk-cpenv, it makes this really easy and gives the artist a little menu before the app starts to choose between “Houdini with Arnold” and “Houdini with Renderman”.

You can also configure who has access to any of these environments and its per project, so very easy to setup software plugins per project and per person if needed.

Honestly, setting up a package manager will save you a lot of headache!

1 Like
5

Hey Ricardo,

thanks for your input. Yes I think sooner or later I will have a look at a proper package manager.

My original questions is till open tough. Does anyone know a solution?
How can I supply something to **kwargs or how would I get the menu name of the clicked item of the desktop app in the BeforeAppLaunch class?

6

Not sure, I thought it was supplied.

Could you “fake it” by adding a command line argument and re-parsing that in your hooks?

What determines which renderer is needed? Project?

7

Yes i tried faking it with cli args but then I get an error message on houdini startup… I now ended up creating two before_app_launch.py files and refer one or the other in the tk-multi-launchapp.yml file. So i have two entries there for houdini arnold and houdini renderman. Not optimal and not very DRY but at least I got it to work.

1 Like
8

Thats at least much neater and proper.

Still, when you get some time… package management :smiley:

1 Like
9

Yeah will definitely look in to it :smiley: Thanks again for your tips!

1 Like