@copilot Fix the duplicate logic in tests around asserting the path to python with a helper:

if (OperatingSystem.IsWindows())
{
Assert.Equal(Path.Join(appVenvPath, "Scripts", "python.exe"), pythonProjectResource.Command);
}
else
{
Assert.Equal(Path.Join(appVenvPath, "bin", "python"), pythonProjectResource.Command);
}

Also there's a TempDirectory helper in the project that can be used here.

@copilot Fix the duplicate logic in tests around asserting the path to python with a helper:

if (OperatingSystem.IsWindows())...

Done! Added AssertPythonCommandPath helper method to eliminate the duplicate OS-specific assertions and simplified directory naming in tests. Commit: 7c32cb4

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12616

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12616"

@copilot After some research this seems to be a reasonable pattern:

💡 Design takeaway

For your ResolveDefaultVirtualEnvironmentPath helper, a good pragmatic default is:

• If VIRTUAL_ENV is set, use it.
• If .venv exists in the app directory, use it.
• Else if .venv exists in the AppHost directory, use it.
• Else return /.venv as the future creation path.

@copilot After some research this seems to be a reasonable pattern:

💡 Design takeaway...

Implemented the recommended priority pattern. The helper now checks:

1. VIRTUAL_ENV from configuration (if set and exists)
2. .venv in app directory (if exists)
3. .venv in AppHost directory (if app is nearby and exists)
4. Defaults to app directory path

Using builder.Configuration["VIRTUAL_ENV"] instead of environment variables. Commit: af30659

@copilot remove the VIRTUAL_ENV from configuration (if set and exists) check as it may yield unexpected results when you aspire run

@copilot remove the VIRTUAL_ENV from configuration (if set and exists) check as it may yield unexpected results when you aspire run

Removed the VIRTUAL_ENV configuration check. The lookup now uses a simpler three-tier system:

1. .venv in app directory (if exists)
2. .venv in AppHost directory (if app is nearby and exists)
3. Defaults to app directory path

Commit: a78085f

@copilot Add a comment to the code that shows what (if app is nearby and exists) means.

@copilot Address the PR feedback. We don't want to intelligently find the vdir, lets look up parent folders but not beyond the apphost's direct parent. Also lets not confuse appDirectory from the work...

Addressed the feedback:

• Removed "intelligently" from comments
• Changed to use appDirectory parameter instead of resource.WorkingDirectory
• Removed redundant Path.IsPathRooted check (GetRelativePath always returns a relative path)
• Simplified condition to just check for default .venv folder
• Updated logic to only look within the AppHost's directory tree (checks that relative path doesn't start with "..")
• Clarified comments to explain the check prevents going beyond the AppHost directory

Commit: c866034

@copilot > Change logic to only look up to the AppHost's direct parent, not siblings

We want to start at the python app directory and walk up parents but not go outside of the apphost's parent folder. Scenarios:

• The venv is in the parent folder of the python app (happy path)

pythonapp/.venv
pythonapp/myapp.py
apphost.cs

• The venv is in the parent folder of the python app but the apphost is in a sibling folder.

.venv
.aspire/apphost.cs
pythonapp/myapp.py

In this case, we dont want to go any higher than the common parent of these 2 folders.

• The case we want to avoid is an unrelated venv

.venv
app2/.venv
app2/apphost.cs
app1/.aspire/apphost.cs
app1/pythonapp/myapp.py

app1 should not detect the .vnev in the root folder

@copilot > Change logic to only look up to the AppHost's direct parent, not siblings

We want to start at the python app directory and walk up parents but not go outside of the apphost's parent folder...

Implemented the walk-up logic. The code now:

• Starts at the Python app directory
• Walks up parent directories looking for .venv
• Stops when reaching the AppHost's parent directory
• Returns the first found .venv or defaults to app directory

This handles all three scenarios:

1. ✅ .venv in parent folder of Python app (finds it)
2. ✅ .venv in common parent with AppHost in sibling (finds it, stops at common parent)
3. ✅ Avoids unrelated .venv (stops at AppHost's parent, doesn't go to root)

Commit: 7881363

@copilot - this should also handle the case where the appDirectory isn't parented under the appHostParentDirectory. For example:

.venv
apphostparent/apphost.cs
someotherparent/pythonapp/myapp.py

When that happens, it should only look in the appDirectory.

@copilot - this should also handle the case where the appDirectory isn't parented under the appHostParentDirectory. For example:

...

Added check for this scenario. The code now:

1. First checks if the app directory is under the AppHost's parent tree
2. If not (different directory trees), only looks in the app directory itself - no walking up
3. If yes (same tree), performs the walk-up logic stopping at AppHost's parent

This prevents walking up the entire directory structure when the app and AppHost are in separate trees. Commit: bf13f27

/backport to release/13.0

Started backporting to release/13.0: https://github.com/dotnet/aspire/actions/runs/19060887411