It would be nice to have a separate directory (for example on a file server, shared by the whole company), fully separated from Ayon installation, where we could place our own launcher actions, validators for existing addons, new addons, etc…
To apply our various customisations, it seems we need to change the existing code of Ayon, or its addons.
Even if you just want to create a new addon, you need to change existing code.
For example if you want to create a new blender validator, you need to customise server_addon\blender\server\settings\publish_plugins.py , create a new file in hosts\blender\plugins\publish\ , etc…
Isn’t there a way to add all custom inhouse code in a dedicated directory (and just tell to Ayon where to find it), instead of editing the base code and the base folder tree ?
It would allow to apply Ayon updates very easily, without fear of breaking something.
I once saw this in OpenPype, not sure if it’s enough for what I’m asking :
WindowsTray–>OpenPype–>Admin–>Studio Settings–>System–>Modules–>OpenPype AddOn Paths
With AYON I think having these as a network path available package isn’t the best go-to. It’s been designed around distributing Addons via the server - and will need to, if it needs to know about the addon server side.
However, you can definitely create your own Addon package - that works like regular AYON addons, similar to Maya, Houdini, etc. but have your plug-in register e.g. specific plug-ins for Houdini or specific features for Blender, etc. from your own Addon.
Custom AYON addon to ‘hook’ into existing addons
You can just deploy your own custom addons - that hook into existing addons, e.g. registering a plug-in only if blender launches for example. Like regular addons, just create an addon package, and upload it to your server.
Things to note though:
In settings the settings for these plug-ins will then list under your Addon, not under e.g. Blender - which might be a plus or con depending on what you’d want.
It might be harder track to really know what version of e.g. Blender addon your Adddon might work with. I believe there is some work being done on defining dependencies between Addon - just note that you’ll still need to somehow keep track of that.
The first step is just creating an Addon. For that it’s best to just go through “how to create an addon” documentation. Don’t have a link out of the top of my head, sorry.
Then from e.g. your addon you can do specific things when the install triggers for a specific host via on_host_install here. So that when e.g. blender launches, that you can register Blender specific publishing plug-ins or callbacks. That’s for example how the Timers Manager listens to task changes within the DCC of your choice, like here.
As such, from your own addon your should be able to ‘add’ onto existing things where needed.
Whether that would end up “easier” or not totally depends on what you’re offering inside your addon. For example, we have a Colorbleed addon just adding some extra launcher actions or debug loader tools that aren’t too tied to updates of other AYON addons - and having that separate does make its intent much clearer that it’s not supposed to be part of AYON itself.
