Update custom fields when publishing

[philip.scadding]

@benwall

If I understand correctly, {self} will look in /install/app_store folder, then check for the file in engine if it fails ? What is the use of {self} ?

No {self} will only look in the local folder for the app, engine or framework. So in this case, as the hook is for the tk-multi-publish2 app, it will look within that app’s bundle. It won’t also check the engine.
You can read more about what those tokens do here (you need to scroll down a short way).

You can introduce inheritance using : which is also discussed in these two posts:

Hook inherit from base class and multiple location

Hi Pritish Welcome to the forums and thanks for posting this here! The following is supported: "{$HOOK_PATH}/path/to/foo.py:{$HOOK_LOCATION_50}/path/to/fooChild.py" This will mean that the hook class in fooChild.py will derive from the class in foo.py. However, this syntax isn’t supported: "{$HOOK_PATH}/path/to/foo.py;{$HOOK_LOCATION_2}/path/to/fooBar.py;" I assume by the syntax you would like to provide a list of locations in which to look for the hook? If that is the case then I think …

Can I use multiple collectors in tk-multi-publish2?

Hey Matt Welcome to the forums!! In a way, you’re correct in that you can only have one collector per Publish2 settings block, unlike the plugins where you can list multiple. However, you can use inheritance to subclass the base collector plugin. When setting the hook paths you can define a chain of inheritance by separating the paths using :. In your example, the order of inheritance is (from base to subclasses) The collector from the publish2 app ({self}/collector.py). Then you have the …

Inheritance would allow you to have that fallback behavior so that if a method wasn’t defined in the engine hook, it could look in the app’s hook, (normal python inheritance behavior.)

@benwall

Why is the file loaded twice in this yml for several DCC, once from {self} and once from {engine}?

That’s a really good question and I can see why it looks like it is the same thing loading twice but, despite the name, they are being treated as two separate plugins. The key is to look at what collected items they act on.

{self}/upload_version.py - This is the upload_version plugin that comes with the publish2 app, so it is not specific to any engine in particular. It is designed to handle specifically "file.image" and "file.video" collected items.

{engine}/tk-multi-publish2/basic/upload_version.py - This plugin comes from the tk-photoshopcc engine and as such can be written in a way that is specific to Photoshop. It responds to "photoshop.document" type collected items.

So by having both of these plugins registered as separate plugins rather than inheriting from each other, they are able to handle different collected items separately.