Working with OpenPype, where would be the best place for studio specific code? For example got Ftrack actions that needs to be referenced in the settings relative to the OP install directory.
Should we make an Addon to store custom code?
Continued from Discord; Discord
Addons are the best place for studio specific code.
There is an example OpenPype/openpype/modules/example_addons at develop · ynput/OpenPype · GitHub and all modules have some docs OpenPype/openpype/modules at develop · ynput/OpenPype · GitHub
And where does the addon live?
Do we put it in the OP repository and maintain this as a branch?
Separate repository that gets pointed to in the settings modules/addon_paths.
How does this work when distributing the pipeline?
You can give OpenPype additional path for your custom addons in system settings /modules/addon_paths
Usually we’d store those custom one on the network somewhere
When distributing the pipeline, either through an installer or zip, will these addon paths be ingested?
They won’t. For a completely remote setup, you’ll need to include them in your codebase before making a new distributable zip.
We didn’t give this a whole lot of love since it was introduced. It wasn’t used that much with remote people and with the switch to new architecture in AYON, it would be a wasted effort.
So technically we could have a folder addons, which ignores everything inside for git. Then we could have studio repositories inside there to distribute and reference relative to the installation folder?
> openpype
---> addons
-------> studio_addon
---> client
---> hooks
---> ...
For what it’s worth - the addons not deploying along has been the reason why’ve just put our addon modules in the actual openpype/modules folder so they’d come along with the .zip. Plus it allowed me to easily keep the addon compatibility in sync with the OpenPype versioning. There’ve been so many refactoring lately (due to Ayon dev) that I’ve had to change imports and some function calls in the custom modules that it was a big plus that I had it just bundled in my own branch within OpenPype. I’ve no idea how to set up a remote addons (for modules) yet at the same time pick a version of a module related to the OpenPype version, I don’t believe that functionality is there.
I’m not saying it’s how it should be done, but it turned out fine for us. Especially since we named the module folder something specific to our studio there haven’t really been issues with merge conflicts or alike.
I’ve no idea how to set up a remote addons (for modules) yet at the same time pick a version of a module related to the OpenPype version, I don’t believe that functionality is there.
Thinking about this now. I guess since settings are versioned you can have multiple addon paths, depending on the OpenPype version and having related settings for each version - not very friendly to manage maybe but doable perhaps?
Possible but your approach is the easiest if you’re keeping a fork anyway. Addon distribution is quite a large chunk of work still to be finalised even in AYON even though the base of it is already in.
1 Like
We can add addons subfolder for v3 as another option to add custom addons to build or zip. It’s just matter of time investment.
It would be hell to manage addons this way for us, as each client would have to have different build and zips.
This won’t be needed in AYON where each addon is deployed per addon version.
Absolutely fair for Ynput to handles client specific code, in whatever way is easiest. For a technician handling a single studio though, I feel like including it within the OP repository makes the most sense, but open to any suggestions that makes distribution path agnostic.