[QUAD] Nuke Payload: Fix farm renderering (Add Gizmos and plugins to the NUKE_PATH)

[BenSouchet]

Changelog Description

Paragraphs contain detailed information on the changes made to the product or service, providing an in-depth description of the updates and enhancements. They can be used to explain the reasoning behind the changes, or to highlight the importance of the new features. Paragraphs can often include links to further information or support documentation.

Additional info

Paragraphs of text giving context of additional technical information or code examples.

Testing notes:

1. start with this step
2. follow this step

[MustafaJafar]

Does setting the necessary environment variables in Application settings fix this problem ?

I'm not sure if you are using OpenPype standalone or OpenPype as AYON Addon?

[BenSouchet]

Does setting the necessary environment variables in Application settings fix this problem ?

I'm not sure if you are using OpenPype standalone or OpenPype as AYON Addon?

We are using OP not Ayon, this issue is present on all OP version up to the last version (3.18.11) not tested in AYON but the logic should be the same.

The deadline job are sent directly with OP not manually submitted.

When sending a job to your deadline farm you need to have all your plugins and gizmos (that was loaded on the submitted scene) to be in the NUKE_PATH.
The goal isn't to hardcode the gizmo and plugins in the NUKE_PATH from within the Application settings but to retrieve the currently loaded paths (so all your plugins and gizmos, even no coming from OP will work on farm) used by nuke to add then for the job.

[BigRoy]

This goes against a lot of the designs of AYON - but even in OpenPype. The intent has always been that the farm worker should build up the environment that makes sense on that worker - and not blindly copy from the source machine who submitted the job. This would not work on e.g. mixed farms (linux + windows) or potentially other configs too.

The goal isn't to hardcode the gizmo and plugins in the NUKE_PATH from within the Application settings but to retrieve the currently loaded paths (so all your plugins and gizmos, even no coming from OP will work on farm) used by nuke to add then for the job.

If they are NOT coming from OpenPype or AYON - where do they come from? I assume they are still 'managed' by the studio admin and deployed in a manner (e.g. network location). Or are you referring to some sort of setup where the artist, live in the application, defines extra dependencies to load?

What I'm wondering is - OpenPype and AYON have been completely able to define external tools/plug-ins, across multiple platforms using application environments, but even better using Tools environments.

That does leave the question that @MustafaJafar asked. What would make these particular paths not suited to be managed by an admin?

---

I'm inclined to close this; however knowing about your use case may highlight an actual workflow issue that is somehow not solved by OpenPype x AYON so will leave it open to continue discussion.

[MustafaJafar]

Thanks @BigRoy for expanding on this topic.

So, Typically, tools that are used across the studio should be managed by admins via environment variables.
I think this PR helps if artists are allowed to install any custom tools on their machines (which may happen with small teams from what I've seen in different places).
However, this indeed goes against the OP/AYON. one reason could be that nothing really guarantees that these tools exist on the farm machines. unlike with using Tools, AYON will always set these up based on the OS of the farm machine.