Anatomy: expand user and vars in root paths by antirotor · Pull Request #1884 · ynput/ayon-core

antirotor · 2026-06-08T17:13:00Z

Changelog Description

Expand variables and user ~ in root paths.

Roots like ~/foo or $HOME/foo or {HOME}/foo should all resolve correctly. Note that this feature needs to be used with care as dynamic roots can break a lot of things if not used properly.

Additional info

This is alternative to #1882

Testing notes:

Publishing to roots with ~ should work as expected
Loading should work too

Copilot

Pull request overview

This PR extends anatomy root handling so root definitions containing ~, $VAR/${VAR}, or {VAR} can be resolved correctly, and so root-template detection can match paths even when only one side (stored root vs input path) is expanded.

Changes:

Expand ~ and environment variables when computing the current-platform root value.
Enhance find_root_template_from_path to compare both original and expanded forms of both stored roots and input paths.
Add an isolated unit-test module covering root matching and remapping scenarios, including env-var and ~ expansion cases.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 5 comments.

File	Description
`client/ayon_core/pipeline/anatomy/roots.py`	Adds `expanduser`/`expandvars` to root value resolution and expands matching logic in `find_root_template_from_path`.
`tests/client/ayon_core/pipeline/anatomy/test_root_item.py`	Adds unit tests for root resolution, matching, and remapping with expanded/unexpanded inputs.
`tests/client/ayon_core/pipeline/anatomy/__init__.py`	Adds package marker for the new test module location.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

iLLiCiTiT · 2026-06-23T14:21:20Z

What is the use-case of having ~ or env in anatomy roots? Allowing it might block us on implementing server side handling of paths.

antirotor · 2026-06-23T14:33:45Z

What is the use-case of having ~ or env in anatomy roots? Allowing it might block us on implementing server side handling of paths.

The use case is client request to be able to use gdrive folder that is per user mounted in their respective home dirs.

iLLiCiTiT · 2026-06-23T15:04:59Z

The use case is client request to be able to use gdrive folder that is per user mounted in their respective home dirs.

I'd say that this is what should be used.

Why I'm against: This will open can of worms. Allowing to do this "easily" looks like you can safely do it, but there is a ton of caviads related to this approach that might make us look bad.

I might be wrong, summoning @BigRoy for opinion.

antirotor · 2026-06-23T15:36:47Z

'd say that this is what should be used.

This is really not practical for whole studio setup. You would have to do it for every site.

and add some type annotations

BigRoy · 2026-06-24T07:52:15Z

Why I'm against: This will open can of worms. Allowing to do this "easily" looks like you can safely do it, but there is a ton of caviads related to this approach that might make us look bad.

I agree with this. The tricky thing is that these expanded root paths and their 'context' are stored in a variety of places, e.g. in publishes, suddenly we're passing the context as root[work] with the user location instead of the actual root of the current platform. Or even making a rootless path for something from another user's machine will not succeed (not sure if relevant to anything.)

But regarding using "site root overrides":

This is really not practical for whole studio setup. You would have to do it for every site.

This is also agree with. Which makes me think what technically differs between a site root override and this? (Except for the fact that the expanded path is set somewhere?)
The USD resolver would now also need to trigger the expandvars (assuming USD can't load directly from a path set as ~/something?

@iLLiCiTiT from a pipeline/technical perspective code-wise. How much does site specific root overrides really differ from expanding the vars?

I think this will need thorough testing, cross-platform with multiple users/home directories - and possibly even with the USD resolver resolving to a published product that uses ~?

iLLiCiTiT · 2026-06-25T07:47:09Z

How much does site specific root overrides really differ from expanding the vars?

At the end the important bit is that it can be resolved server side, service side, or in USD resolver.

assuming USD can't load directly from a path set as ~/something

Also ${HOME}/something or $HOME/something and %HOME%/something on windows because of expandvars and {HOME}/something because of format_map(os.environ).

antirotor · 2026-06-25T08:36:46Z

While I agree that this might be dangerous and might break things - there are many more similar things around pipeline. My point is that nothig is forcing you to do it. It just gives you a possibility. If this is documented properly, it is up to the studio to go that way or not.

Linux allows you to type sudo rm -rf / and it has its own uses, but noone force you to write it.

antirotor · 2026-06-25T08:38:27Z

%HOME%/something

this won't work as it is not expanded by python

iLLiCiTiT · 2026-06-25T08:52:46Z

this won't work as it is not expanded by python

It is. I just chose wrong env key which is not set by windows. %USERPROFILE%/something woult be expanded.

The thing is that with this is looks like you can safely use it, which is not true, you'll block yourself from some features, and it might not work all the time, and it will look like our fault.

iLLiCiTiT · 2026-06-25T08:55:39Z

-            )
-        except KeyError:
+            self.value = (
+                os.path.expandvars(


If we gona do it, I'm against using expandvars, only {ENV} should be possible.

what is the reason? My argument is that using paths with $VAR inside is pretty standard.

It is standard, but then you have to support it at every place which is using roots, including USD resolver, it is hard to find out if it is missing, and what exact variable it is (it does not have strictly defined end the the variable name). $MY_custom_var is valid env key, but how you find out if it should be $MY or $MY_custom...

I guess the behavior is clearly defined. VAR = "foo":

lorem $VAR: lorem foo
lorem $VARipsum: lorem
lorem $VAR ipsum: lorem foo ipsum
lorem %VAR%: lorem foo
lorem %VAR%ipsum: lorem fooipsum

os.path.expandvars() is taking care of that in python and the resolver needs to implement {VAR} format anyway so adding $VAR and/or %VAR% is trivial at that point. But I don't really mind. @BigRoy ?

You can't easily find out if it is missing (without validating it for each platform) and there are limitations, e.g. you can't use $VARipsum (which is missing in your example). I'm 100% against it. I know it is "known", but it is not easily detectable and easy to validate.

It is there:

lorem $VARipsum: lorem

But it also supports curly bracket format that is standard too. So if you want this to work, you can:

lorem ${VAR}ipsum: lorem fooipsum

and all that is supported by os.path.expandvars()

This is unresolved expanding and you have no idea it is unresolved

print(os.path.expandvars("$NOTEXISTING")) >>> $NOTEXISTING

This does require to be more specific, something that should be filled is not

import os os.environ["TEST"]="value" print(os.path.expandvars("$TEST_something")) >>> $TEST_something

Supporting this will only bring issues. At the end it does what the python formatting does, but with less control and more headaches for us.

iLLiCiTiT · 2026-06-25T08:56:13Z

+            # Expand variables in the stored root path so we can compare it
+            # against an already-expanded input path (and vice-versa).
+            expanded_root_path = self._clean_root(
+                os.path.expandvars(os.path.expanduser(root_path))


Root paths should be already expanded in cleaned_data.

I am not sure I get it - it is not expanded there, only for current platform. so are you suggesting that the expansion logic should be moved to ... probably _clean_path()?

iLLiCiTiT · 2026-06-25T08:56:40Z

+        # is already expanded while the caller passed an unexpanded path, or
+        # to normalise both sides consistently.
+        expanded_mod_path = self._clean_path(
+            os.path.expandvars(os.path.expanduser(path))


We should not allow to pass in not expanded path.

why? shouldn't one place take care of that intead reimplementing the logic in all places where you want to use this feature before calling find_root_template_from_path()?

If you call find_root_template_from_path you should have full path, not ~/some/file.

that is what you get now:

ar = AnatomyRoot( parent=..., root_raw_data={"linux": "/home/user/projects"}, name="work", ) success, result = item.find_root_template_from_path("~/projects/shot/file.ma")

you'll get result == "{root[work]}/shot/file.ma"

it handles matching unexpanded paths to expanded roots in various forms (~, $VAR, etc.) and only if it cannot match, it will success == False.

And where you'd get the path "~/projects/shot/file.ma" from?

antirotor · 2026-06-25T15:41:26Z

btw this is draft PR for USD Resolver - ynput/ayon-usd-resolver#80

✨ expand user and vars in root paths

bcb2c1c

ynbot added size/S type: enhancement Improvement of existing functionality or minor addition labels Jun 8, 2026

Merge branch 'develop' into enhancement/YN-0773_expanded-roots

d2a7d2f

antirotor linked an issue Jun 9, 2026 that may be closed by this pull request

YN-0773: make sure variables are expanded in roots #1874

Open

antirotor self-assigned this Jun 9, 2026

antirotor added 2 commits June 18, 2026 18:24

Merge branch 'develop' into enhancement/YN-0773_expanded-roots

9a2e29d

Merge branch 'develop' into enhancement/YN-0773_expanded-roots

2a9d64f

antirotor requested review from BigRoy, Copilot and iLLiCiTiT June 23, 2026 13:35

antirotor added the sponsored This is directly sponsored by a client or community member label Jun 23, 2026

Copilot started reviewing on behalf of antirotor June 23, 2026 13:40 View session

Copilot AI reviewed Jun 23, 2026

View reviewed changes

fix: apply suggestions 🤖

85ca603

antirotor added 3 commits June 23, 2026 18:25

tests: revert the annotations and mock Anatomy in tests instead.

8510253

fix: handle AnatomyRoots mocking even better

9f79e1a

and add some type annotations

fix: handle context in tests

c49633b

iLLiCiTiT reviewed Jun 25, 2026

View reviewed changes

ynbot added this to PR reviewing Jun 25, 2026

ynbot moved this to Review In Progress in PR reviewing Jun 25, 2026

iLLiCiTiT reviewed Jun 25, 2026

View reviewed changes

antirotor mentioned this pull request Jun 25, 2026

Expand variables in path ynput/ayon-usd-resolver#80

Draft

Merge branch 'develop' into enhancement/YN-0773_expanded-roots

3bb45c7

iLLiCiTiT mentioned this pull request Jun 30, 2026

fix: expand user home in anatomy roots #1882

Closed

Merge branch 'develop' into enhancement/YN-0773_expanded-roots

319a2c6

Uh oh!

Conversation

antirotor commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog Description

Additional info

Testing notes:

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

iLLiCiTiT commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antirotor commented Jun 23, 2026

Uh oh!

iLLiCiTiT commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antirotor commented Jun 23, 2026

Uh oh!

BigRoy commented Jun 24, 2026

Uh oh!

iLLiCiTiT commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antirotor commented Jun 25, 2026

Uh oh!

antirotor commented Jun 25, 2026

Uh oh!

iLLiCiTiT commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iLLiCiTiT Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iLLiCiTiT Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

antirotor commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

antirotor commented Jun 8, 2026 •

edited

Loading

iLLiCiTiT commented Jun 23, 2026 •

edited

Loading

iLLiCiTiT commented Jun 23, 2026 •

edited

Loading

iLLiCiTiT commented Jun 25, 2026 •

edited

Loading

iLLiCiTiT commented Jun 25, 2026 •

edited

Loading

iLLiCiTiT Jun 25, 2026 •

edited

Loading

iLLiCiTiT Jul 3, 2026 •

edited

Loading