WSL support for codespace code command

[mattKorwel]

what

provides small documentation update to help wsl2 users get past a cli error. tangentially related to #3526

why

as a wsl2 user when i attempt to open a codespace in vscode, i get a path not found error. it wasn't obvious what the issue was... 'was xdg-open, not finding code? was it because i was running code insiders etc'. also it wasn't clear to me that xdg-open is not installed by default in wsl2.

its worth mentioning that code itself, as well as regular windows programs open fine in wsl2 with out xdg-open which is why its not needed or missed before this.

follow on

https://wslutiliti.es/wslu/man/wslview.html is installed in wsl2 by default and https://github.com/4U6U57/wsl-open is a popular install as well. long term i'd like to see this transparent to the end user. that said given the backlog in #3526 I think a doc update is a sufficiently low hanging fruit.

platform details

❯ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

PS C:\Users\makorwel> wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-20.04 (Default)

[vilmibm]

Agreed that there's a more robust solution but that this is helpful for now, thanks

[mislav]

Sorry to contradict the previous approval, but I would suggest that there is a better way to go about this which wouldn't involve putting the responsibility on the user.

First of all, I do not think we should advertise WSL compatibility specifically. We advertise Windows support and we advertise Linux support; therefore WSL should be implied as a given.

Second, opening URLs and programs from gh should ideally use wslview under WSL instead of xdg-open. In the past, we've added WSL support for URLs in #1708 (although it now lives here). However, the gh cs code command does not use github.com/cli/browser package, but instead uses github.com/skratchdot/open-golang/open, which doesn't support wslview.

A proper fix would be to either submit wslview support upstream to skratchdot/open-golang or to switch opening the vscode:// URL over to the cli/browser package.

[mattKorwel]

i agree with you @mislav but i was just stopping by to be helpful. so i won't have bandwidth to go deeper. i suppose if you are saying your team wants to take this on as feature work that's great.

however, as it stands today we have a broken experience for users, with no guidance or a fix from this team. do as you wish but acknowledging something is broken and providing an intermediate work around seems to me to be a better experience than its just broken.

if you prefer to leave it broken and unacknowledged for users now go ahead and close this issue.

good luck, thanks.

[mislav]

so i won't have bandwidth to go deeper. i suppose if you are saying your team wants to take this on as feature work that's great.

No worries if you don't have time to solve this in a way that I suggested! We appreciate your bug report nevertheless and the suggestion to fix it. I've opened an issue to track this bug and will close this PR in the meantime.