I’m looking into using Ayon to distributing Python+QT-based tools to artists, are there any MVP examples of this?
Current objective is to port a simple standalone Python tool into an Ayon addon, and use Ayon to distribute our tools to artists.
Even without using any of the default addons or pipeline tools, this would prove to be hugely valuable to our studio setup, as it’s currently a bit of a mess to manually build/freeze Python apps for both Windows and Mac, and ensuring artists are using up to date versions.
I see there are two examples in Github
Ayon-addon-template and ayon-example-addon
But these examples have different structures and module names, and no examples for a qt-based client tool.
I looked into the OpenPype addon repo to see if I could find clues there from the Publisher, Launcher and Loader interfaces , but it was a bit of an overwhelming repo. It might also be a poor example, as you guys are working towards splitting it into individual addons.
Any pointers in the right direction available for getting a proof of concept running?
I see. I didn’t realize it needed to be part of the build process.
I thought each desktop tool (like Publisher, Loader, Launcher) could be distributed as separate addons, and then be updated from the server and pulled by artists, without having to build the base executable every time.
Or it might be a thing Ayon is aiming for, but it’s not ready yet?
Ayon does do that differently as far as I know, yes.
Also, step 1 would really only be needed if whatever code you write requires its own dependencies to be supplied with OpenPype deployments that you’re not also offering on PYTHONPATH.
If the tools you write are just “expose some python tools” to the user then just creating custom tool entries that add to PYTHONPATH like in Step 2) or Step 3).
Step 2 would be global for all launches in your studio (and even OpenPype itself I believe),
Step 3 would provide the tools solely for certain application launches and will need to be enabled as a tool on asset (folders in Ayon) individually.
So even though they are numbered in succession you can PICK ANY of 2) or 3) - you don’t need both.
I see. Starting to untangle things.
To clarify - I’m looking at distributing standalone Python tools to run independently from DCCs, similarly to the Launcher.
I had made the assumption that since Ayon is meant to be (to my understanding) fully modular, that I could strip away the existing tools in the tray menu, and replace them with my own tools.
As I do not want to use the built-in OpenPype tools (to start with at least).
I assumed that if I disabled the OpenPype plugin, I would be left with an Ayon Tray app that was running in the background, but have none of the tools or services exposed. Giving me a “blank slate” to then make addons that would show up in the tray menu.
But as I tried disabling OpenPype addon, then the Ayon application wouldn’t start at all.
So it seems to me that the whole tray app is OpenPype itself, and not so much a standalone Ayon application. (?)
The OpenPype build version being exposed in the tray menu should’ve tipped me off though, so an oversight on my end.
Is this just a temporary thing, or do I have to build “my own” Ayon.exe with custom tray app logic looking for addons with tools?
Or should I make my own fork of the OpenPype addon, and strip away the features I don’t need, and upload that to the Ayon server?
as far as I know, yes.
Because OpenPype is transitioning to Ayon, you may find these boundaries are not distinct.
you can also tell how these are quite similar.
OpenPype
Ayon
I didn’t try to add a new button in the tray app
However you don’t have neither edit openpype or ayon itself.
you can do so by only making an addon
for example check kitsu module or Clockify module in openpype, and that’s what modular really means where you have the core system with all these addons, it’s really similar to Legos
As far as I know the design intent with Ayon is that you can EVEN ignore using the Launcher / Tray completely which does mean that whatever the OpenPype addon is now likely will split into further module separation so that potentially even the Tray itself is a bare tray application.
How far that’ll be stripped and what the design intent is there I suspect @milan can offer some insight on. I recall reading that at least the OpenPype bundle/package would still get split into much smaller modular parts.
Anyway, as Mustafa does explain you can definitely add your own entries in the Tray with modules (like legos!) but how much of the tray menu you can actually ‘remove’ currently I’m not sure.
Pretty much the only reason it’s not quite smooth at the moment is the beta status.
OpenPype addon’s only reason is that it hosts most of the pipeline code of other addons for the transition period. As we start moving all of them out (which should start happening very soon btw), it will eventually end up with just the barebones core functionality and will be renamed to AYON core addon
At the moment we’re expecting this addon to stay as the only compulsory one as it holds some crucial logic for the desktop part of the pipeline.
That being said, as @BigRoy mentioned, technically there is nothing stopping you from just using the server and building your tools around it in any way you see fit. If you’d like to stick to at least our launcher, you’ll most probably also need at the very least the core addon even down the line.
I’ve made some progress, by digging into the ayon-shotgrid addon developed by @Minkiu and @iLLiCiT .
This addon was not overwhelming with files, and it has tray-integration, so I could use that as a starting point and start to gradually strip away code and make a boilerplate.
Still in the process, but great exercise to understand how things work
I got a bit confused by the difference between addon templates before and after packaging, so I had to install the addon and browse the appData to really understand the difference between development- and client-facing addon code and structure.
Progress is made! And I feel more confident I can do what I want Ayon to do for me
Not quite sure what the most efficient way of developing for Ayon is yet, I’m currently just editing code in the C:\Users\user\AppData\Local\Ynput\AYON\addons directly, and relaunching Ayon Tray to see what happens.
But I figure out once I understand the logic, I can probably develop the tools independently from the addon structure, and port it over to an addon afterwards.
OpenPype had the concept of “running live from the source code” which I believe AYON has too but has likely grown a bit more complex with the separation of addons. However on Discord the exact same question came up here so I wanted to reference it here so you don’t miss what might be offered as a solution there.
Following up on this.
I’ve had a few people reach out in private about how it was done, so I prepared some boilerplate available here with some rough explanations.
Please keep in mind, that this may already be out of date as the Ayon API and best practices has improved. And it goes against the suggested Ayon Addon structure.
This setup was developed with the intention of integrating existing tools and studio pipeline frameworks into Ayon by using the Ayon Addon as a wrapper, without integrating Ayon so heavily into the code that it can’t be used outside an Ayon context.
Thank you @strandli, FWIW I have also created a branch of the ayon-example-addon repo where I am working in completing some boilerplate code, as of now it just has an additional Tray menu entry, it was fairly quick to implement. I think it follows the new Ayon standards, but maybe someone from Ayon can confirm this.
I will later research on how to integrate a simple service as well.
