starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Don't generate WSL distributions for Rancher Desktop #17081

New Issue
Closed
opened 2026-01-31 05:31:41 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 05:31:41 +00:00
Owner
Copy Link

Originally created by @AlexHunterCodes on GitHub (Mar 25, 2022).

Description of the new feature/enhancement

Feature request #3556 suggested blocking Terminal from auto-generating profiles for Docker Desktop's service WSL2 machines, and this was accepted and implemented.

Rancher Desktop is a new alternative to Docker for Windows developed by Rancher/SUSE and optimised for containerd and Kubernetes; and it uses a similar WSL2-based backend with two managed service machines: rancher-desktop and rancher-desktop-data. This leads to Terminal auto-generating profiles for these machines, even if there is no practical reason to ever use them.

A workaround for this is to hide the two entries from the profile list with the Settings GUI or in settings.json:

{
    "guid": "{1cd79813-5972-56cb-badb-ba5ee12693c5}",
    "hidden": true,
    "name": "rancher-desktop",
    "source": "Windows.Terminal.Wsl"
},
{
    "guid": "{1bdae7ec-8ca6-5caa-8453-8b6fe78b2748}",
    "hidden": true,
    "name": "rancher-desktop-data",
    "source": "Windows.Terminal.Wsl"
},

Terminal should extend this blocking feature to include Rancher Desktop's service machines too, with the likelihood of future apps bundling more WSL service machines in mind.

Proposed technical implementation details (optional)

This could be achieved in a few different ways:

  1. The quick fix, add more hard-coded rules to extend the code added in #4156, and hope that loads more apps don't start shipping bundled WSL distros.
  2. Suggestion from #3556, use metadata to differentiate service machines from user machines during auto-generation. This should probably include an allowlist config option to override this automatic detection when necessary. I'm not sure how feasible this is, as I don't think there's any suitable existing metadata provided by WSL. Maybe the distributions themselves would have to provide some flag for Terminal to detect?
  3. Provide a blocklist config option, which would allow:
    • Apps providing WSL distros to programmatically insert their service machine's names into settings.json during app installation
    • Users to manually specify machines to skip, which also allows service machine developers (like me) greater flexibility in general.

Main benefit of options 2 and 3 is eliminating the burden on the Terminal team of maintaining a hard-coded blocklist, and dealing with further requests like these in future. I could see both 2 and 3 in combination being the ideal solution in the long term.

Originally created by @AlexHunterCodes on GitHub (Mar 25, 2022). # Description of the new feature/enhancement Feature request #3556 suggested blocking Terminal from auto-generating profiles for Docker Desktop's service WSL2 machines, and this was accepted and implemented. [Rancher Desktop](https://github.com/rancher-sandbox/rancher-desktop) is a new alternative to Docker for Windows developed by Rancher/SUSE and optimised for containerd and Kubernetes; and it uses a similar WSL2-based backend with two managed service machines: `rancher-desktop` and `rancher-desktop-data`. This leads to Terminal auto-generating profiles for these machines, even if there is no practical reason to ever use them. A workaround for this is to hide the two entries from the profile list with the Settings GUI or in settings.json: ```javascript { "guid": "{1cd79813-5972-56cb-badb-ba5ee12693c5}", "hidden": true, "name": "rancher-desktop", "source": "Windows.Terminal.Wsl" }, { "guid": "{1bdae7ec-8ca6-5caa-8453-8b6fe78b2748}", "hidden": true, "name": "rancher-desktop-data", "source": "Windows.Terminal.Wsl" }, ``` Terminal should extend this blocking feature to include Rancher Desktop's service machines too, with the likelihood of future apps bundling more WSL service machines in mind. # Proposed technical implementation details (optional) This could be achieved in a few different ways: 1. The quick fix, add more hard-coded rules to extend the code added in #4156, and hope that loads more apps don't start shipping bundled WSL distros. 2. Suggestion from #3556, use metadata to differentiate service machines from user machines during auto-generation. This should probably include an allowlist config option to override this automatic detection when necessary. I'm not sure how feasible this is, as I don't think there's any suitable existing metadata provided by WSL. Maybe the distributions themselves would have to provide some flag for Terminal to detect? 3. Provide a blocklist config option, which would allow: - Apps providing WSL distros to programmatically insert their service machine's names into `settings.json` during app installation - Users to manually specify machines to skip, which also allows service machine developers (like me) greater flexibility in general. Main benefit of options 2 and 3 is eliminating the burden on the Terminal team of maintaining a hard-coded blocklist, and dealing with further requests like these in future. I could see both 2 and 3 in combination being the ideal solution in the long term.
claunia commented 2026-01-31 05:31:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 25, 2022):

@benhillis & @craigloewen-msft as an FYI.

Was there ever any further progress on enabling WSL dristros to mark themselves as service machines vs actual user-facing ones? That was a agood idea that I don't believe ever really got traction.

Manually suppressing these distros is easy, but that's just a game of wack-a-mole. I feel like if two different entities have done this now, it's only a matter of time till more copy the pattern. There needs to be a more official way to clearmy markup these distros.

@zadjii-msft commented on GitHub (Mar 25, 2022): @benhillis & @craigloewen-msft as an FYI. Was there ever any further progress on enabling WSL dristros to mark themselves as service machines vs actual user-facing ones? That was a agood idea that I don't believe ever really got traction. Manually suppressing these distros is easy, but that's just a game of wack-a-mole. I feel like if two different entities have done this now, it's only a matter of time till more copy the pattern. There needs to be a more official way to clearmy markup these distros.
claunia commented 2026-01-31 05:31:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 25, 2022):

(I may also suggest posting a similar issue on the WSL repo to make sure this stays on their triage queue 😝)

@zadjii-msft commented on GitHub (Mar 25, 2022): (I may also suggest posting a similar issue on the WSL repo to make sure this stays on their triage queue 😝)
claunia commented 2026-01-31 05:31:44 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 25, 2022):

Fragment extensions may be a good distro-driven way to handle this! It's worth checking out whether fragments can set hidden when updating a profile.

It's slightly worse than us not generating them, as they'll show up in the settings UI.

@DHowett commented on GitHub (Mar 25, 2022): Fragment extensions may be a good distro-driven way to handle this! It's worth checking out whether fragments can set `hidden` when updating a profile. It's slightly worse than us not generating them, as they'll show up in the settings UI.
claunia commented 2026-01-31 05:31:44 +00:00
Author
Owner
Copy Link

@AlexHunterCodes commented on GitHub (Mar 25, 2022):

(I may also suggest posting a similar issue on the WSL repo to make sure this stays on their triage queue 😝)

Doesn't look like a feature request was ever created on the WSL repo following up on the original metadata idea from #3556, so I'm not sure its even in their triage queue (unless there were off-GitHub discussions about it).

@zadjii-msft About posting a similar issue to WSL, were you talking to me or the WSL devs you tagged?

@AlexHunterCodes commented on GitHub (Mar 25, 2022): > (I may also suggest posting a similar issue on the WSL repo to make sure this stays on their triage queue 😝) Doesn't look like a feature request was ever created on the WSL repo following up on the original metadata idea from #3556, so I'm not sure its even in their triage queue (unless there were off-GitHub discussions about it). @zadjii-msft About posting a similar issue to WSL, were you talking to me or the WSL devs you tagged?
claunia commented 2026-01-31 05:31:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 6, 2022):

We may want to follow up on this discussion upstream in https://github.com/rancher-sandbox/rancher-desktop/issues/818. I don't totally think it's tenable for us to continually manually exclude applications that are doing weird things with WSL distros like this. A better way would be having some property that apps can set to mark their distros themselves as not user-facing, but I suspect that'll never happen (@craigloewen-msft can correct me if I'm wrong).

Admittedly though, https://github.com/microsoft/terminal/pull/4156/files was super trivial and would not take a lot of work for someone to add additional distros there. As much as I'd prefer pursuing the technically correct solution, just monkey-patching that would be the quickest way to the best results.

Note

Walkthrough

Literally just copy #4156, for these two distros.

@zadjii-msft commented on GitHub (Jul 6, 2022): We may want to follow up on this discussion upstream in https://github.com/rancher-sandbox/rancher-desktop/issues/818. I don't totally think it's tenable for us to continually manually exclude applications that are doing weird things with WSL distros like this. A better way would be having some property that apps can set to mark their distros themselves as not user-facing, but I suspect that'll never happen (@craigloewen-msft can correct me if I'm wrong). Admittedly though, https://github.com/microsoft/terminal/pull/4156/files was super trivial and would not take a lot of work for someone to add additional distros there. As much as I'd prefer pursuing the _technically correct_ solution, just monkey-patching that would be the quickest way to the best results. > **Note** > ## Walkthrough Literally just copy #4156, for these two distros.
claunia commented 2026-01-31 05:31:44 +00:00
Author
Owner
Copy Link

@craigloewen-msft commented on GitHub (Jul 12, 2022):

@zadjii-msft we definitely have it on our backlog to have a way for distros to mark themselves as non-user facing, but it isn't on our short term roadmap yet.

@craigloewen-msft commented on GitHub (Jul 12, 2022): @zadjii-msft we definitely have it on our backlog to have a way for distros to mark themselves as non-user facing, but it isn't on our short term roadmap yet.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings good first issue Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Terminal Product-WSL
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17081
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?