Simplify ProfilePathInfo and ensure profile variable is set during startup#2287
Simplify ProfilePathInfo and ensure profile variable is set during startup#2287JustinGrote wants to merge 5 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR refactors profile path handling and changes host startup so $PROFILE is initialized even when profile scripts are not loaded.
Changes:
- Splits profile handling into setting
$PROFILEand loading profile scripts. - Adds startup flow to always set the profile variable and only conditionally load profile scripts.
- Converts
ProfilePathInfointo a positional record struct and updates tests for profile-variable behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
test/PowerShellEditorServices.Test/Session/PsesInternalHostTests.cs |
Updates and adds tests for profile loading and $PROFILE initialization. |
src/PowerShellEditorServices/Services/PowerShell/Utility/PowerShellExtensions.cs |
Separates $PROFILE setup from profile script loading. |
src/PowerShellEditorServices/Services/PowerShell/Host/PsesInternalHost.cs |
Calls profile-variable setup during startup before optional profile loading. |
src/PowerShellEditorServices/Hosting/HostStartupInfo.cs |
Refactors ProfilePathInfo into a record struct. |
src/PowerShellEditorServices.Hosting/Internal/EditorServicesRunner.cs |
Always creates a ProfilePathInfo from configured profile paths. |
Comments suppressed due to low confidence (1)
src/PowerShellEditorServices/Services/PowerShell/Utility/PowerShellExtensions.cs:215
- This repeats the same null-sensitive
PSObject.AsPSObjectcall used when setting$PROFILE. If the profile object is unavailable and the paths are null, enabling profile loading will still fail here even if setting the variable is made tolerant; reuse the normalized profile value or coalesceCurrentUserCurrentHostbefore wrapping it.
PSObject profileVariable = PSObject.AsPSObject(profilePaths.CurrentUserCurrentHost);
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot fix test: |
… result Agent-Logs-Url: https://github.com/PowerShell/PowerShellEditorServices/sessions/6d4f3ac9-ed54-4532-97ae-33f69934f59a Co-authored-by: JustinGrote <15258962+JustinGrote@users.noreply.github.com>
Head branch was pushed to by a user without write access
Fixed in Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@andyleejordan this should be good to go, I don't think the themis test failure is related, I suspect it has a race condition. |

PR Summary
Refactor the
ProfilePathInfostructure to use a record type for simplicity. Ensure the profile variable is set during the startup process, regardless of whether profiles are loaded. This is to make behavior consistent with ConsoleHost andpwsh -noprofile($profile is available regardless of if profiles were actually loaded or not)PR Context
This change improves the clarity and efficiency of profile path handling and guarantees that the
$PROFILEvariable is always set, enhancing the initialization process for users.