As far as I know, Traditionally, we would set environment variables by setting them permanently in the system environment variables OR set them before launch using shell scripts or using some tools like Rez.
Things become more dynamic and much easier, in general you can do all of the mentioned above from one UI, it’s two actually but it’s still the same program and deployment to all artist machines is as simple as clicking save button!
AYON Configuration
You can add environment variables in different places:
Global Studio Environment variables. It will be available in Launcher and for all DCCs.
Setting location: Studio: ayon+settings://core/environments
DCC Specific, and DCC Version Specific It will be available for all sessions of this specific DCC or DCC version.
Setting location: Studio: ayon+settings://applications/applications/{app_name}
Tool Groups: A flexible configuration to be used on demand. where you can add it to a project, folder path and filter by DCC or DCC version
Setting location: Studio: ayon+settings://applications/tool_groups
OP doesn’t suppose or use tools by default with projects and assets
Projects can inherit tools settings from default project, however it happens while creation then save that as override. so, projects inherit while creation not after creation., that’s why step 2 is required
I believe the same happens with assets and their parent folder, that’s why step 3 is required
Testing
The most basic test “as a user” to check if the tool is there in DCC or not, user may look in menus or shelves.
e.g. I was testing adding MOPs as tool in my Houdini. So, as I user I’m expecting to be able to find MOPs nodes after launching Houdini.
Check the tools that were set in AYON applications settings It simply shows the settings assigned to your folder or task within the Project Editor. It does not provide information on whether the tool has been imported.
Current folder path: /Assets/Character/moco
Current task: cfx
Tools: ['houdini-mops/v1-6']
Check if environment variables were actually set in your application.
import os
from pprint import pprint
from ayon_core.pipeline.context_tools import (
get_current_folder_path,
get_current_task_entity
)
env_var = "MAYA_OP_TOOL_ENV"
folder_path = get_current_folder_path()
print("Current folder path: {}".format(folder_path))
current_task = get_current_task_entity()
print("Current task: {}".format(current_task["name"]))
print("--- Contents for environment variable: {}".format(env_var))
pprint(os.getenv(env_var , "").split(";"))
print("--- End of contents")
Example output: “from Maya”
Current folder path: /Assets/Character/moco
Current task: cfx
--- Contents for environment variable: MAYA_OP_TOOL_ENV
['This is a maya ayon tool environment']
--- End of contents
Example output: “from Houdini”
Current folder path: /Assets/Character/moco
Current task: cfx
--- Contents for environment variable: MAYA_OP_TOOL_ENV
['']
--- End of contents
This was the same asset lamp from the previous example.
These code snippets were provided by @BigRoy. Many thanks!
Troubleshooting
The only troubleshooting I can think of is to check
if environment variables were written correctly, try testing them in your DCC env file
if tools were set to a particular project, try checking OP studio project settings
if tools were set to a particular asset, try checking OP project manager
Existing assets/shots do not inherit the new default project settings for Tools
It’s good to note that Configuring tools for a Project sets the default value for new assets but does not influence any existing assets/shots whatsoever.
As such, if you want to apply the tools to an existing project with existing assets you’ll still need to mass-update all existing assets to be configured with the new tools via Configuring tools for an Asset.
Projects can inherit tools settings from default project, however it happens while creation then save that as override. so, projects inherit while creation not after creation., that’s why step 2 is required
But I feel like it’s something that’s usually missed. I knew originally that was the case and often forgot about it when I started using OpenPype as a new user.
Also, testing as a dev for debugging purposes
I think it added the literal '{HOUDINI_PATH}' because HOUDINI_PATH wasn’t defined in the first place, no worries anyway.
10 minutes ago it didn’t work because of a space
who would know that a space in the env var can be painful!
Yes - it does that, but for 99% of the cases that should just get ignored. But the environment resolving indeed doesn’t ignore an unset key to avoid other subtle bugs.
Houdini + htoa
It’s also good to note that if e.g. each of your Houdini application version environments e.g. define HOUDINI_VERSION=19.5.532 then your tools can also use that nicely, so that if you e.g. have a plug-in that’s different per houdini version you can then have it add the one dynamically, e.g.:
HTOA tool global environment: I cut off the license server stuff
So that you only need to define a single HTOA entry for a version that applies to multiple houdini version instead of defining a htoa tool version PER htoa version and houdini version. Like so:
Hey @BigRoy@mustafa_jafar, I’ve got this strange issue. I added four tools, but only the last package in alphabetical order is loading. The other three plugins are not loaded and are not showing. Any specific script issues?
I’ve had issues long time ago that looked similar, but that was due to that there was at least one tool that was overwriting HOUDINI_PATH instead of appending to it - it’s hard to tell if that’s the case because then we’d need to see how your global environment, application environments and each tool environment is configured to see if any of those are wrong.
E.g. if LABS/19-5 would be setting HOUDINI_PATH instead of appending it might be the case that it stops the value from AELIB/V1 to propagate, etc.
Not sure if that’s the issue you’re facing but it might be.
Note that the HOUDINI_OTLSCAN_PATH is currently set to “override” the existing value completely if another tool or environment than the one for QLib tool would set it. So you’d also need to do the ["newpathshere", "{HOUDINI_OTLSCAN_PATH}"] way of setting it to also preserve any existing values, etc.
FYI, method append (that’s a Houdini package thing, not an environment variable thing) should not do anything actually so I suspect something else magically resolved your issue.
Hey Guys, Can you try adding MOPS, AELIB, and “SideFX Labs” if possible? After some research, I started facing an issue when adding SideFx Labs as a Tool. I tried multiple ways with no luck. Please share the tool script if it’s working for you guys🙏
I feel like the easiest way to investigate and try to replicate is if you can share your setup.
You seem to be using HOUDINI_PATH to point to .json files that themselves also change the environment (since that’s what Houdini packages do basically).
Could it be the .json packages themselves that are doing something different with your environment than you expect (like overriding instead of appending?)
Anyway, share your houdini packages (particularly the json files) and Tools configurations and it might help point out what’s up.
I rely on houdini installer to add it. but anyways
you don’t have to add version or enable as OP will taker care of that
so you may add two settings h19.0 and h19.5
I didn’t test this code, because I don’t have these packages explicitly outside houdini
Also note that in OP settings
$PATH will be resolved by Houdini unlike "{PATH}" will be resolved by OP this may lead to confusion at first especially if you are copying and pasting packages to OP
A rule of thumb always use "{ANY_VAR}" inside OP settings even if "$ANY_VAR" works, this should eliminate any confusion
for example your qlib configuration : in my opinion it’ll be better to be
you don’t have to worry about the trailing & and you needn’t to write "your path to qlib" inside square brackets because it’s one value.
square brackets are used when you have many values like "HOUDINI_OTLSCAN_PATH" in the above code
Hi, Finally, writing code in this order worked for me. It looks like the order of the package load is very important. Loading the packages first caused the menu bar problem.
Hi @BigRoy
i was tried to create the new asset like you said, its only inherit when creation not for existing asset
I already setup the default tools ( step 2 )
but when create the new asset in project manager/ftrack its still empty on tools column, it didnt use the default tools…
did i miss something or just missunderstanding? Im using Ftrack addons
I might be mistaken, but I believe in AYON the new asset actually inherits it from the nearest parent, which in this capture would be asset/prop. I suspect @milan@martin.wacker know more about what the intended behavior there would be.
Also, if you’re using the Ftrack addon I believe the intent is that you create and manage the assets and shots via Ftrack and do not edit it in Ayon - again, I might be wrong and @milan will confirm or correct me.
I also tested in Ftrack, but it seems there might be a bug, maybe?? The only attribute that doesn’t sync with the Ayon database is “tools_env”. I tried changing the frame range in Ftrack from 1001 to 900 on asset build, and inside Maya it changed accordingly, but not for the tools. It’s still empty.
and there is no log error
Hi @BigRoy, I think I found the problem. The top parent folder, like “asset/shot,” wasn’t configured with tools when it was initially created. After I recreated the hierarchical structure and deleted all top folders, configuring them with the new settings, all assets inherited the tools as expected. I believe I didn’t configure it properly initially.
The important note I’ve realized is that the parent folder on entities needs to be configured first.
However, changing the “Info Tools” from Ftrack didn’t update the tools in the database. It seems that it needs to be done by the project manager, Ayon, specifically for the tools, but for some reason, it didn’t sync properly if from Ftrack Tab Info.
