ynput/ayon-applications

AYON addon to maintain applications

AYON Applications

Applications addon does care about launch of applications in AYON workspace. It defines and provides API to launch applications.

ayon-applications's Issues

Allow shell style environment variable access for paths.

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

Currently I would like to add this path within my executables inside ayon+settings://applications/applications/blender/variants/3/executables/linux/0:
/home/$USER/opt/blender_launcher/custom/Blender_Sandbox/blender

The AYON launcher does not seem to support that.
It naturally does support this:
/home/hannah/opt/blender_launcher/custom/Blender_Sandbox/blender

How would you imagine the implementation of the feature?

I would like to be able to use environment variables in OSes that have folders on user-level to ensure the path towards the directory of the executable can be developed based per individual.

I was considering f strings but that is too risky, tokens were given as an advice instead by my mentor:

/home/{$USER}/opt/blender_launcher/custom/Blender_Sandbox/blender

That would mean the instructions given are in the back-end. Leaving it still as easy for adaptation in the current situation.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

No response

Tools enhancement

Description

PR #16 added option to define tools with profiles, but for some production cases it would be helpful to define them per task. That is also possible with the settings, using task path, but it is hard to maintain and there is no visual indication how to know "What tools will be used on this task?".

Suggested implementation

After discussion with @mkolar we've came to possible solution. Attributes were just not designed for this kind of feature. So we still use profiles as base functionality, but we'll also supply option to "override" profiles with "tools" stored to "data".

Migrate applications and tools attributes to settings

Using attributes to manage the applications and tools attribute creates issues when staging Application settings affecting them.
Using settings in the Applications addon would streamline the configuration UX and let us fully leverage the staging worflow.

We need to:

1. Add Project level settings to Applications:
   1.1 to associate applications variants to host/task using Profile settings.
   1.2 to declare groups of tools and associate them to host/task using Profile settings.
2. Add a Project level toggle setting to activate this new behavior instead of the current (legacy) one.
   2.1 Add a deprecation warning whenever the pipeline requests the application list or the tools list using the legacy behavior.

We will later turn this warning into an error and change the toggle default value to the new behavior.
We will later remove the old behavior and the toggle.

1.1 and 1.2 must be project level, but the applications and tools variant definition can stay at sudio level as they currently are.
There might be a challenge in providing a dropdown to fill the profile settings. If needed, we could consider having all defined in studio+project levels settings.

2.1 needs a way to issue the deprecation warning. This will be handled in another issue (https://github.com/ynput/AYON-Epics/issues/28). In the meanting we will just log to strerr, but using a dedicated interface which will later be hooked to the server's warning system.

1.2 is a very different way to configure tools, but we do believe this new workflow is at least as powerfull as the legacy one.
We need to find a nice name for these "groups of tool". We're open for suggestions!

[cuID:AY-5752]

Allow to define custom icon uri

Description

Right now we do allow to use only application icons that are available inside applications addon, so custom applications can't set custom icon.

That is due to recent changes in applications addon and movement out of ayon-core.

How would you imagine the implementation of the feature?

Because webactions are comming, we should support custom uri for icon in additional applications. I guess the icons could be supplied by an addon,

Question that might rise is how to make it dynamic enough, the final uri could be like https://my.ayon.server/addons/myAddon/1.1.1/private/icons/myApp.png but the template probably should be {ayon_url}/addons/myAddon/{addon_versions[myAddon]}/private/icons/myApp.png so it can be used dynamically, ayon_url would be filled with whatever client needs and addon_versions would be filled with addon versions based on addons available in bundle that is used.

Blender: Pass system pythonpath checkbox

Description

Adding --python-use-system-env to arguments is the most common issue with blender because a) some don't know it has to be added b) they usually forget.

Suggested solution

Possible solution to this could be to add simple checkbox to blender application variant. Applications manager could just add the argument to arguments if the checkbox is checked. If it would be enabled by default, it would behave 99.99% correctly.

AY-6320_override ENV on local machine

Please describe the feature you have in mind and explain what the current shortcomings are?

we had the functionality to override some ENV variables on local machine.

use case:

redshift plugin is installed in different location on a machine so we need to override the ENV variable to point to the correct location

How would you imagine the implementation of the feature?

No response

Describe alternatives you've considered:

No response

Additional context:

link to discussion on Discord
(might be a private channel)

This issue was automatically created from Clickup ticket AY-6320

Farm Render jobs collect env using launch type "farm_publish" instead of "farm_render"

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior:

Recent refactoring seems to have changed the launch type for extractenvironments logic as used by e.g. the Deadline's GlobalJobPreLoad logic.

It currently seems to force LaunchTypes.farm_publish in the logic here - also since 0.3.0

Previously it was e.g. LaunchTypes.farm_render in Ayon Core 0.2.1 and also in OpenPype

The LaunchTypes.farm_render currently even seems unused?

Expected Behavior:

Elaborate the differences between the two - and use the correct one when relevant.

I assume for the deadline render jobs it should be using the LaunchTypes.farm_render?

Version

1.0.0

What platform you are running on?

Windows

Steps To Reproduce:

1. Pre launch hooks with LaunchTypes.farm_render do not run in deadline render.

Are there any labels you wish to add?

• I have added the relevant labels to the bug report.

Relevant log output:

No response

Additional context:

No response

Only available applications slowdown

Current Behavior

When Only available applications is checked (ayon+settings://applications/only_available), discovering of applications is a lot slower in launcher tool. Don't know why but it may slow down discovery by seconds.