I'm not sure if this is faster, but we may not need to go through the env keys because the anatomy object already has this piece of information.
I wonder if there's a cached anatomy object instead of creating/querying it.

I mostly refrained from doing this due to speed reasons - getting the Anatomy object usually results in quite some queries which I hoped to avoid.

Plus, technically - even if the anatomy has it defined.. if it's not in os.environ it wouldn't actually work in the current session if the anatomy had changed since startup?

I'm thinking it may be better to just 'cache it once' in the current session since that part of os.environ (for the roots) shouldn't update on context changes regardless. Right @iLLiCiTiT ?

I'm thinking it may be better to just 'cache it once' in the current session since that part of os.environ (for the roots) shouldn't update on context changes regardless.

The envs were aded in Pype 2. We didn't have real usage for them since OpenPype, but didn't remove them.

I mostly refrained from doing this due to speed reasons - getting the Anatomy object usually results in quite some queries which I hoped to avoid.

If you pass in project_entity it does not do any additional queries.

But what if you're loading from library project? The environments are completelly different in that case, or?

Does having the key in os.environ mean it's actually added to hscript or doesn't it?
Honestly, I don't know because the last item I plated with env vars I was checking if the variables is set in both environ and hscript.

It is not set to hscript no, however houdini vars still expand them.

As far as I know, Houdini expands them in order:

• is hscript var? -> expand
• is env var? -> expand

BTW with Anatomy you could just use this and skip filepath_from_context.

current_project = get_current_project_name()
project_name = context["project"]["name"]
if project_name == current_project:
    anatomy = Anatomy(
        project_name, project_entity=context["project"]
    )
    return get_representation_path(
        context["representation"],
        anatomy.roots.root_environmets_fill_data()
    )
return super().filepath_from_context(context)

Does that leave the roots in tact? Also, good point on only supporting current project there!

The envs were aded in Pype 2. We didn't have real usage for them since OpenPype, but didn't remove them.

If we do remove them - then it makes sense to explicitly 'enable' them in ayon-houdini to support this Houdini feature. We can make a PR for that once we need at that point in time.

Does that leave the roots in tact? Also, good point on only supporting current project there!

Default behavior of root_environmets_fill_data is to return env keys as values for root {"work": "$AYON_AYON_PROJECT_ROOT_WORK", ...} -> which is what you're guessing here, whereas the suggested code does fill it with the root that is really requested by the template.

EDITED: Question is if get_representation_path is able to handle that? I don't remember if it still does validate path existence?

I wonder if going the other way is easier to understand and maintain.
I'm assuming the longest match will result in a smaller string (unless the root name is big enough to break this assumption)
Also, we can skip sorting if we the matching is one path.

I like this less because it'd mean we'd always be checking against all roots, even if we had already matched one. So it'd perform less optimal. However, sure - the amount of roots may never grow that large that it'd really be a problem.

Overall I just did a prototype here and did not look at 'cleaning the code' at all - it was merely testing whether this could be functional.

the amount of roots may never grow that large that it'd really be a problem.

I agree. but, the code just looks hard to read that's why I tried picking a different approach.