fix: Override environment variables based on priority #3940

magentaqin · 2025-06-12T15:10:38Z

Description

This PR is created to solve Environment variable of tasks are broken when defined in surrounding scope , Unit tests and integration

What functionality changes I made

1.Change the priority of environment variables
Original Order(highest to lowest):
activation scripts > activation.env > activation scripts of dependencies > environment variables > task specific envs
Current Order(highest to lowest):
task specific envs > activation scripts > activation.env > activation scripts of dependencies > environment variables

2.What code changes I made
1) get_export_specific_task_env function refactor in executable_task.rs.
Previously, std::env::var has deterministic issues. So I updated get_export_specific_task_env to let it explicitly receive the parameter command_env.
priority array: store the keys of the environment variable map. For extension, as in the future, there may be other kinds of environment variable map passing in.
env_map map:

{
  "COMMAND_ENV": {...},
  "TASK_SPECIFIC_ENV": {...}
}

and we can merge the map according to the priority order. Finally, we get the export_merged array and export all the environment variables to the shell.
I also add escape logic and exclude environment variables that can't be overidden.
2) run_activation in activation.rs
process the activator.run_activation() result and handling the overidden stuff.

TO FIX

Test compatibility issues on windows platform, which causes the pipeline fails.

magentaqin · 2025-06-18T09:09:49Z

I find the priority order of activation scripts and activation.env is changed by activator.run_activation, which is the function run_activation in rattler_shell crate. Details can be seen here: https://github.com/prefix-dev/pixi/pull/3940/files#diff-f84977a6e7fdf8147b0d4b75f15a45112eff4507146389b1fb84e4647e0489c8

As required, we need to change the priority order. So I need to pass the second parameter to run_activation to override the environment variable.

To test whether the override function works, I constructed a hash map called opt_map, it has the key "CMAKE_ARGS" and the value "Foo123".

Before run_activation is called, I printed the current activator. It reads environment variable I defined in activation.env, that is "CMAKE_ARGS": "-DCMAKE_BUILD_TYPE=Debug"

After run_activation is called, I printed activator again. It reads environment variable I defined in activation_scripts, that is CMAKE_ARGS": "from_activation_script

Expected behavior:
After run_activation is called, activator should be CMAKE_ARGS": "Foo123, as I passed it as second parameter and overrides it.

ruben-arts · 2025-06-23T12:41:24Z

This change will introduce an issue for a use case we supported previously. That is the use of environment variables as arguments for functions. e.g.:

[tasks.start]
cmd = "echo $ARG"
env = { ARG="default" }

Usage:

~/envs/args  
➜ pixi run start
✨ Pixi task (start): echo $ARG
default

~/envs/args  
➜ ARG=hoi pixi run start
✨ Pixi task (start): echo $ARG
hoi

Users could define their task like that. With this change that use-case will break and will always have the default value.

We currently support arguments. But these are not named, only positional. So to get something like this working:

[tasks.problem]
cmd = "echo {{ ARG1}} {{ ARG2 }} {{ ARG3 }}"
args = [
  {arg = "ARG1", default = "default1"},
  {arg = "ARG2", default = "default2"},
  {arg = "ARG3", default = "default3"}
]

You need to run the following

➜ pixi run problem "hello 1" "test 2" "test 3"
✨ Pixi task (problem): echo hello 1 test 2 test 3
hello 1 test 2 test 3

The problem arrises when you only want to override the 3 option. you need to do:

➜ pixi run problem "" "" "test 3"              
✨ Pixi task (problem): echo   test 3
test 3

I think before we break that other behavior we need to improve the ux of tasks. As there is no way to define named variables right now. There is one more trick people could use:

[tasks.trick]
cmd = "echo {{ ARG }}"
args = [{arg = "ARG", default = "$ARG"}]

This would bring back the use of environment variables. But it doesn't allow a user to set a default as the evaluation happens after the template replacement.

Proposal

I think we can already improve this experience with a few convincing features:

Named arguments, in the cli, have a way to specify which argument you want to modify.
Extend the minijinja functions with the ability to read env vars: args = [{arg = "name", default = "{{ env.ARG or "default_value" }}"}]

@Hofer-Julian & @magentaqin please let me know what you think.

When we merge this we should see if it introduces really non-working setups and work to improve the UX of tasks as required.

magentaqin · 2025-06-24T13:25:58Z

Hi, @ruben-arts! Thanks for your suggestion.

My Question

Could you please explain more about the [tasks.trick] problem?

[tasks.trick]
cmd = "echo {{ ARG }}"
args = [{arg = "ARG", default = "$ARG"}]
`

If you run ARG=123 pixi run trick
✨ Pixi task (trick): echo $ARG

123

From my understanding, this satisfies our expectation.

As this PR is to solve priority issues, for the CLI optimization part, shall we open another PR and another issue to solve it separately?

My Proposal

Based on your proposal, my proposal is:
1.Support named arguments and alias for named arguments.

[tasks.foo]
cmd = "echo {{ input }} {{ output }} {{ verbose }}"
args = [
    {name = "input", alias = "i", default = "Input file"},
    {name = "output", alias = "o", default = "out.txt"},
    {name = "verbose", alias = "v", default = false}
]

Then when you run like this:

pixi run foo -i input.txt
✨ Output
input.txt "out.txt" false

2.Support both default value and environment variable.

[tasks.foo]
cmd = "echo {{ ARG }}"
args = [{name = "ARG", default = "${ARG:-Guest"}}]

Then when you run like this:

ARG=123 pixi run foo
✨ Output
123
Then when you run like this:
pixi run foo
✨ Output
Guest

3.Support required field to force the user set value to override and support interactive prompts.(prompt, type and options)

[tasks.deploy]
cmd = "deploy {{ env }} {{ version }} {{ confirm }}"
args = [
    {
     name = "env",
     required = true, 
     prompt = "Deployment environment", 
     type = "select", 
     options = ["test", "staging", "production"]
   },
   {name = "version", default = "latest", prompt = "Version to deploy"},
   {name = "confirm", type = "bool", required = true, prompt = "Confirm deployment"}
]

$ pixi run deploy
✨ Output
Deployment environment: production
Version to deploy (latest): v1.2.3
Confirm deployment (y/N): y
Running: deploy production v1.2.3 true

Hofer-Julian

Looks promising at first glance.

Added a few comments for now, one of them might be the cause of your Windows struggles.

Will do a more extensive review next round

Hofer-Julian · 2025-06-27T08:41:13Z

src/task/executable_task.rs

+        "PIXI_PROJECT_ROOT",
+        "PIXI_PROJECT_NAME",
+        "PIXI_PROJECT_MANIFEST",
+        "PIXI_PROJECT_VERSION",
+        "PIXI_PROMPT",
+        "PIXI_ENVIRONMENT_NAME",
+        "PIXI_ENVIRONMENT_PLATFORMS",
+        "CONDA_PREFIX",
+        "CONDA_DEFAULT_ENV",
+        "PATH",
+        "INIT_CWD",
+        "PWD",
+    ]


Good that you thought of that!

Hofer-Julian · 2025-06-27T08:50:56Z

src/task/executable_task.rs

-fn get_export_specific_task_env(task: &Task) -> String {
-    // Append the environment variables if they don't exist
+/// Get the environment variable based on their priority
+fn get_export_specific_task_env(task: &Task, command_env: &HashMap<OsString, OsString>) -> String {


Instead of converting it later on, just require HashMap<String, String> right away

good suggestion!

Hofer-Julian · 2025-06-27T08:51:19Z

src/task/executable_task.rs

-                export.push_str(&format!("export \"{}={}\";\n", key, value));
+        // If task.env() and command_env don't have duplicated keys, simply export task.env().
+        if env.keys().all(|k| !command_env_converted.contains_key(k)) {
+            println!("env.keys() {:?}", env.keys());


Get rid of this println

sorry, I'll remove it. I was thinking about debugging on the windows pipeline.

Hofer-Julian · 2025-06-27T08:52:14Z

src/task/executable_task.rs

+            }
+        } else {
+            // Env map
+            let mut env_map: HashMap<&'static str, Option<IndexMap<String, String>>> =


Suggested change

let mut env_map: HashMap<&'static str, Option<IndexMap<String, String>>> =

let mut env_map: HashMap<&'static str, IndexMap<String, String>> =

Is the Option really necessary here?

yes, because the value of TASK_SPECIFIC_ENVS can be None, and the value of env_map should stay the same. So I use Option here.

Hofer-Julian · 2025-06-27T08:53:26Z

src/task/executable_task.rs

+        let should_exclude = override_excluded_keys.contains(key.as_str());
+        if !should_exclude {
+            tracing::info!("Setting environment variable: {}=\"{}\"", key, value);
+            // Platform-specific export format with proper escaping


We didn't have any of this escaping beforehand. Why is it necessary now?

I was trying to solve the windows pipeline error. Let me first remove it!

this platform specific export format should be deleted and just

export.push_str(&format!("export \"{}={}\";\n", key, value));

will be enough

let me try this!

Hofer-Julian · 2025-06-27T08:55:21Z

tests/integration_python/test_run_cli.py

+    manifest = tmp_pixi_workspace.joinpath("pixi.toml")
+    script_manifest = tmp_pixi_workspace.joinpath("env_setup.sh")
+    toml = f"""
+    [project]


Suggested change

[project]

[workspace]

We try to use workspace everywhere nowadays

Hofer-Julian · 2025-06-27T08:57:27Z

tests/integration_python/test_run_cli.py

+    pixi-foobar = "*"
+    """
+    test_script_file = """
+    #!/bin/bash


This will only work on Unix.

Something like this should work:

[target.unix.activation] scripts = ["scripts/activate.sh"] [target.win-64.activation] scripts = ["scripts/activate.bat"]

This will only work on Unix.

Something like this should work:

[target.unix.activation] scripts = ["scripts/activate.sh"] [target.win-64.activation] scripts = ["scripts/activate.bat"]

good catch!

Hofer-Julian

Let's clean up the tests a bit. Will then focus on the actual implementation.

Good work so far!

Hofer-Julian · 2025-07-10T12:43:48Z

tests/integration_python/test_run_cli.py

+    [tasks.task]
+    cmd = "echo $MY_ENV"
+    [tasks.foo]
+    cmd = "echo $MY_ENV"
+    [tasks.foobar]
+    cmd = "echo $FOO_PATH"
+    [tasks.task.env]
+    MY_ENV = "test456"


Suggested change

[tasks.task]

cmd = "echo $MY_ENV"

[tasks.foo]

cmd = "echo $MY_ENV"

[tasks.foobar]

cmd = "echo $FOO_PATH"

[tasks.task.env]

MY_ENV = "test456"

[tasks.task]

cmd = "echo $MY_ENV"

env = { MY_ENV = "test456" }

[tasks.foo]

cmd = "echo $MY_ENV"

[tasks.foobar]

cmd = "echo $FOO_PATH"

this makes it a bit more readable IMO

Hofer-Julian · 2025-07-10T12:45:01Z

tests/integration_python/test_run_cli.py

+    windows_toml = f"""
+    [workspace]
+    name = "test"
+    channels = ["{dummy_channel_1}"]
+    platforms = ["linux-64", "osx-64", "osx-arm64", "win-64"]
+    [activation.env]
+    MY_ENV = "test123"
+    [target.unix.activation]
+    scripts = ["env_setup.sh"]
+    [target.win-64.activation]
+    scripts = ["env_setup.bat"]
+    [tasks.task]
+    cmd = "echo $env:MY_ENV"
+    [tasks.foo]
+    cmd = "echo $env:MY_ENV"
+    [tasks.foobar]
+    cmd = "echo $env:FOO_PATH"
+    [tasks.task.env]
+    MY_ENV = "test456"
+    [dependencies]
+    pixi-foobar = "*"
+    """


What is the difference to the unix_toml?
Can't we use the same toml here?

it's the compatible windows test pipeline issue, let me revert to the original one!

Hofer-Julian · 2025-07-10T12:45:30Z

tests/integration_python/test_run_cli.py

+    if platform.system() == "Windows":
+        manifest.write_text(windows_toml)
+        script_manifest.write_text("""
+        $env:MY_ENV = "activation_script"
+        $env:FOO_PATH = "activation_script"
+        """)
+    else:
+        manifest.write_text(unix_toml)
+        script_manifest.write_text("""
+        #!/bin/bash
+        export MY_ENV="activation_script"
+        export FOO_PATH="activation_script"
+        """)


We don't need an if condition here.
Just write it in both cases

Hofer-Julian · 2025-07-10T12:46:21Z

tests/integration_python/test_run_cli.py

+    # Validate that without experimental it does not use the cache
+    assert not tmp_pixi_workspace.joinpath(".pixi/activation-env-v0").exists()


Suggested change

# Validate that without experimental it does not use the cache

assert not tmp_pixi_workspace.joinpath(".pixi/activation-env-v0").exists()

# Validate that without experimental caching it does not use the cache

assert not tmp_pixi_workspace.joinpath(".pixi/activation-env-v0").exists()

Hofer-Julian · 2025-07-10T12:49:06Z

tests/integration_python/test_run_cli.py

+    # Enable the experimental cache config
+    verify_cli_command(
+        [
+            pixi,
+            "config",
+            "set",
+            "--manifest-path",
+            manifest,
+            "--local",
+            "experimental.use-environment-activation-cache",
+            "true",
+        ],
+    )


I don't really see why you'd set this config here. I feel the test is already pretty complicated as is.

I'll remove it!

Hofer-Julian · 2025-07-10T12:50:04Z

tests/integration_python/test_run_cli.py

+    verify_cli_command(
+        [pixi, "run", "--manifest-path", manifest, "task"],
+        stdout_contains="test456",
+        env={"MY_ENV": "outside_ev"},


Suggested change

env={"MY_ENV": "outside_ev"},

env={"MY_ENV": "outside_env"},

Hofer-Julian · 2025-07-10T12:50:52Z

tests/integration_python/test_run_cli.py

+    verify_cli_command(
+        [pixi, "run", "--manifest-path", manifest, "foo"],
+        stdout_contains="test123",
+        env={"MY_ENV": "outside_ev"},


Suggested change

env={"MY_ENV": "outside_ev"},

env={"MY_ENV": "outside_env"},

Hofer-Julian · 2025-07-10T12:51:46Z

tests/integration_python/test_run_cli.py

+    # Test 3: activation.env > outside environment variable - should use activation.env
+    verify_cli_command(
+        [pixi, "run", "--manifest-path", manifest, "foo"],
+        stdout_contains="test123",


Suggested change

stdout_contains="test123",

stdout_contains="test123",

stdout_excludes="outside_env"

Hofer-Julian · 2025-07-10T12:52:31Z

tests/integration_python/test_run_cli.py

+    # Run an actual install
+    verify_cli_command(
+        [pixi, "install", "--manifest-path", manifest],
+    )


Suggested change

# Run an actual install

verify_cli_command(

[pixi, "install", "--manifest-path", manifest],

)

That shouldn't be necessary

Hofer-Julian · 2025-07-10T12:54:30Z

tests/integration_python/test_run_cli.py

+    verify_cli_command(
+        [pixi, "run", "--manifest-path", manifest, "foobar"],
+        stdout_contains="activation_script",
+    )


I am missing tests here, that environment variables that are set from the outside and are NOT overridden by anything inside Pixi still work as expected

I would also choose the tests a bit different.

So you have this goal:

outside environment variables

activation scripts of dependencies

activation.scripts

activation.env

task specific envs like tasks.start = {cmd = "…", env={ENV_VAR="SOME"}}

So add tests that 5>4, 4>3, 3>2, 2>1 and finally that 1 on its own works
Then you have everything covered

Sorry, I don't quite understand what you mean. Is the test order thing?

I want you to add asserts that "activation scripts of dependencies" wins over "outside environment variables".
"activation.scripts" should win over "activation scripts of dependencies", and so on. If nothing else is set "outside environment variables" should be considered.

2728253#diff-e6813bccd5c3cad11b9c048122f69487eafb612de804912383e94995b10f188b I added the test '"activation scripts of dependencies" wins over "outside environment variables", and update the test order. Have a look!

tests/integration_rust/task_tests.rs

src/task/executable_task.rs

zelosleone · 2025-07-10T15:53:30Z

src/task/executable_task.rs

+        let expected_prefix = if cfg!(windows) {
+            "env:FOO = \"bar\""
+        } else {
+            "export \"FOO=bar\""
+        };


Suggested change

let expected_prefix = if cfg!(windows) {

"env:FOO = \"bar\""

} else {

"export \"FOO=bar\""

};

let expected_prefix = "export \"FOO=bar\"";

zelosleone · 2025-07-11T15:27:33Z

I think there are more than one problem here for windows and in general for the logic of priority listing.

I don't think we should show all the system exports in output, there was a similar case with debugging mode being added in rattler-build and this looks very similar to that in terms of output, since we don't need all of them to be seen and just task-related ones will be enough. This is one of the problems for windows, as deno shell cannot parse everything related to windows correctly (programfiles env names etc.) not to mention that many of them at once, its having hard time even with a special logic to escape quotes.
Additionally, I think the order for placing the function that orders the tasks in priority should be moved to activation state as an async function. Something like:

pub async fn get_task_env_for_task(
    task: &Task,
    environment: &Environment<'_>,
    clean_env: bool,
    lock_file: Option<&LockFile>,
    force_activate: bool,
    experimental_cache: bool,
) -> miette::Result<HashMap<String, String>> {
    let mut env = get_task_env(
        environment,
        clean_env,
        lock_file,
        force_activate,
        experimental_cache,
    )
    .await?;
    if let Some(task_env) = task.env() {
        for (key, value) in task_env {
            env.insert(key.clone(), value.clone());
        }
    }

    Ok(env)
}

Should be more than enough. This will also limit the COMMAND_ENV and TASK_SPECIFIC_ENVS additions where you can safely delete them and just get them from the activation/runtime instead.

Additionally, tests should use .bat for windows (.ps1 extension will give errors)
Also, to add to backwards tick problem of windows you can place

.replace('\\', "\\\\")
.replace('"', "\\\"")
.replace('$', "\\$");

etc. before exporting them as combined env variables (before export push str)

magentaqin · 2025-07-14T20:16:32Z

(^▽^)わくわく, @zelosleone! Thanks for your great effort on this PR and nice suggestion.👍🏻

1.For the exported script, I agree with u. Now I update my strategy: only export the statement that has key in Task_Specific_Env map.
2. update tests using .bat for windows

Based on the above updates, the test pipeline on windows passed! 👏🏻

For the priority order handling logic, I think we need further discussion. To be more decoupled, I still think they should be put in executable_task module instead of activation module.
In the previous commits, I've tried escaping characters. But it has nothing to do with the error. As the old version of the functionality doesn't have escaping and there're a lot of escaping cases, I would suggest the task in a separate PR(...this PR hasn't been closed for a quite long time😭)

… of them

…attler_shell crate

…variable setting

…nvironment variable'

Hofer-Julian force-pushed the bugfix/environment-variable-priority branch from c963cd4 to 0886b67 Compare June 18, 2025 13:43

magentaqin force-pushed the bugfix/environment-variable-priority branch from b6a5b74 to 9186613 Compare June 24, 2025 11:50

magentaqin changed the title ~~Override environment variables based on priority~~ bugfix: sort environment variables based on priority Jun 26, 2025

magentaqin force-pushed the bugfix/environment-variable-priority branch from 5c63837 to c8bc900 Compare June 26, 2025 08:54

magentaqin changed the title ~~bugfix: sort environment variables based on priority~~ fix: Sort environment variables based on priority Jun 26, 2025

magentaqin force-pushed the bugfix/environment-variable-priority branch from e96b34a to c8bc900 Compare June 26, 2025 09:17

magentaqin marked this pull request as ready for review June 26, 2025 15:52

magentaqin changed the title ~~fix: Sort environment variables based on priority~~ fix: Override environment variables based on priority Jun 26, 2025

Hofer-Julian requested changes Jun 27, 2025

View reviewed changes

magentaqin force-pushed the bugfix/environment-variable-priority branch 3 times, most recently from 382b459 to 35cdb9f Compare July 3, 2025 05:37

magentaqin requested a review from Hofer-Julian July 3, 2025 08:58

magentaqin force-pushed the bugfix/environment-variable-priority branch 2 times, most recently from acb9791 to 1499388 Compare July 9, 2025 13:42

Hofer-Julian reviewed Jul 10, 2025

View reviewed changes

zelosleone reviewed Jul 10, 2025

View reviewed changes

tests/integration_rust/task_tests.rs Outdated Show resolved Hide resolved

zelosleone reviewed Jul 10, 2025

View reviewed changes

tests/integration_rust/task_tests.rs Outdated Show resolved Hide resolved

zelosleone reviewed Jul 10, 2025

View reviewed changes

src/task/executable_task.rs Outdated Show resolved Hide resolved

zelosleone reviewed Jul 10, 2025

View reviewed changes

src/task/executable_task.rs Outdated Show resolved Hide resolved

zelosleone reviewed Jul 10, 2025

View reviewed changes

magentaqin added 4 commits July 16, 2025 14:21

feat: override environment variables based on priority and export all…

59bf9f8

… of them

draft: override environment varibales of run_activation function in r…

08bab98

…attler_shell crate

feat: [activation.env] should override activation scripts

5cb6857

chore: remove unecessary blank line

5e4bb7d

magentaqin added 24 commits July 16, 2025 14:21

fix: fix compatible issues

0cb4682

fix: add single quote

d97abca

chore: remove spaces in test_task_with_env

fcdaf30

fix: in windows, child shell should inherit the parent's environemnt …

972cc64

…variable setting

fix: in windows, child shell should inherit the parent's environemnt …

5149986

…variable setting

chore: add debugger helper for 'test_task_with_env'

ea6ea61

fix: revert changes

e936ebb

fix: remove set

b959284

fix: fix powershell issues

290ac95

fix: fix powershell compatible issues

b17b122

fix: fix powershell compatible issues

ac968ad

fix: fix escaping issues

7ab69f2

chore: print err for test_task_with_env

d1bfa2f

fix: Use PowerShell environment variable syntax

6ca2d41

chore: add println for 'expected_prefix'

2c43bba

fix: replace .bat with ps1

c6c692b

chore: print echo_cmd

0ed9bad

fix: remove unecessary windows code

1d492cc

fix: fix linting error

47d3713

fix: Only the keys that are in TASK_SPECIFIC_ENVS map would be exported.

6689964

fix: use '. bat' for windows

91b957c

chore: print env set in windows

2d652bf

fix: specify 'target.win-64.activation' in pixi.toml

644237a

chore: remove unecessary echo

b74990b

magentaqin force-pushed the bugfix/environment-variable-priority branch from 304022c to b74990b Compare July 16, 2025 12:22

magentaqin added 3 commits July 17, 2025 08:31

chore: update test order

9068f11

test: add tests for 'activation scripts from dependencies > outside e…

2728253

…nvironment variable'

doc: add 'test' section to CONTRIBUTING.md

1ae6d46

magentaqin requested a review from Hofer-Julian July 18, 2025 08:57

Merge branch 'main' into bugfix/environment-variable-priority

ee54f58

	let mut env_map: HashMap<&'static str, Option<IndexMap<String, String>>> =
	let mut env_map: HashMap<&'static str, IndexMap<String, String>> =

		# Validate that without experimental it does not use the cache
		assert not tmp_pixi_workspace.joinpath(".pixi/activation-env-v0").exists()

	stdout_contains="test123",
	stdout_contains="test123",
	stdout_excludes="outside_env"

fix: Override environment variables based on priority #3940

Are you sure you want to change the base?

fix: Override environment variables based on priority #3940

Uh oh!

Conversation

magentaqin commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

What functionality changes I made

TO FIX

Uh oh!

magentaqin commented Jun 18, 2025

Uh oh!

ruben-arts commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposal

Uh oh!

magentaqin commented Jun 24, 2025

My Question

My Proposal

Uh oh!

Hofer-Julian left a comment

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!

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!

Hofer-Julian left a comment

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!

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

magentaqin commented Jun 12, 2025 •

edited

Loading

ruben-arts commented Jun 23, 2025 •

edited

Loading

zelosleone commented Jul 11, 2025 •

edited

Loading