Is there any way to setup Toolkit so that a plugin can be an uploaded file in SG and downloaded to the artist machine when they launch a DCC?
Say for instance, I were to develop a plugin for remote artists to use on a project. When they launch a DCC like Max or Maya it would check a SG entity for the uploaded file containing the latest/approved plugin for their use. It would then download and install the plugin for them. Is that something the Toolkit and SG is capable of handling?
One thing you could do is create a framework or app that contains your plugin.
Store that framework or app in Shotgun as an upload and include it in your config using a Shotgun upload descriptor. Then when your config is bootstrapped/ the use picks the project in Shotgun Desktop (if you are using a distributed config like @Ricardo_Musch suggested ) then it will download your custom App/Framework containing your plugin.
Then you would need to take over the before_app_launch.py hook and modify the environment to include your plugin that was downloaded in whatever way is correct for the software.
You would have a method in the framework or app that returned the path to the plugin payload, and you would call the method on your custom app or framework from within the hook.
In the outline for setting up the plugin distribution Step 5 talks about modifying the app to use the hook for loading the sg_software_plugin. The folder structure outlined looks like the setup using the default2 tk-config. What would be the file(s) needed to modify when using the basic config? Also, will this distribution work when just launching Toolkit or is it only something setup to pull down the payload when you launch a targeted DCC?
Yeah good point, I’ve updated the post to show where you would make the changes on tk-config-basic as well.
So with my example, I’m expecting that the user will launch the software through Shotgun Desktop or the Shotgun browser integration, every time they want to use the distributed plugins. Even if the plugin doesn’t need to be downloaded, it may still need to be set up again, ie setting the environment to point to it, so that approach will do it when they launch.
I’m not quite sure what you mean by “just launching Toolkit”? Do you mean like running Shotgun Desktop but not launching anything?
You could change it so that the logic was run at a different point, such as via the engine_init.py core hook, obviously, you would need to make a few changes such as pulling down plugins for all software since you won’t be passed on specifically. Also how you “set up” the plugin to be used is up to you, but the before_app_launch.py is a convenient place to do it usually.
Thanks for the update and sorry for any confusion. When I am talking about the Toolkit I am meaning, by simply launching the SG Toolkit interface and not a DCC. This example looks like it would launch and download a Maya/Max/Houdini/etc plugin associated with the launching of a DCC application. I was wondering if this could also be used for a stand alone application that had no reliance on a DCC. And thus, would do the same checks and tool download by simply launching the Toolkit interface.
Your correct my example will only run when you launch Software via the tk-multi-launchapp.
It will not run if for example you run the tk-multi-publish2 app from within SG Desktop.
There is no hook that generically runs when ever an app is about to be launched, so there wouldn’t be a place you could catch that. Instead you would need to use the engine_init.py core hook approach. Though your logic would need to be different if there was no Software entity then how would you know what plugins you should pull for say the publish app. You would need some way to know which plugins you should pull.
Got it, but I was thinking more along the lines of using the same mechanism that pulls down Toolkit to the local user machine to also handle other tools that are not SG related at all. Like general pipeline stuff.
You can do that as well, but then your plugins would need to be in a framework that uses a Shotgun uploaded descriptor, like I mentioned my original message here.
I like the sound of that approach as well, it’s just not the approach we chose to use in the example.
Basically inorder for Toolkit to pull down your plugins when caching the config, your plugins would need to be in a bundle referenced by the config, and a custom framework would seem like the best type of bundle to fulfil that requirement.
I’d have liked to have provided an example of the framework approach as well, but unfortunately, I’ve not had time to tackle that as well.