The 'webbrowser' module throws warnings and bad RC codes when running under Windows Subsystem for Linux (WSL).

This causes libraries that depend on the 'webbrowser' module to mistakenly assume there's been an error opening a URL. An example of this behaviour can be observed running `jupyter-lab` under WSL.

Steps to reproduce:
1. Run Ubuntu (for example) under Windows WSL.
2. `python -m webbrowser https://www.python.org`

Expected result:

The wesite opens.

Actual result:

The website opens but produces a `No valid TTY` message, which also yields a non-zero return code.

I have a patch for this bug that inspects the kernel version (platform.uname) and detects WSL. This is a similar solution that other projects have implemented to tackle this problem. For example, the fish shell project: https://github.com/fish-shell/fish-shell/blob/0e06a53dff5e198c4fcefb6419a53cf1267231a1/share/functions/help.fish#L83.

Windows people, do we support running on WSL?  Is there a buildbot running it?

We don't formally support it yet. We probably need somebody to develop expertise in the emulation layer so that they can work with the Linux distro experts to make sure their distros are doing things properly.

It has no relation at all to our Windows support (right now) - all versions of Python running in WSL 100% believe they are running on whichever Linux distro the user is running.

My code patch uses ‘wslview’, which is a binary that is injected into every
WSL distro and forwards file open commands to windows.

I detect WSL inspecting the kernel version, which includes WSL tagging.

On Tue, Nov 2, 2021 at 3:05 PM Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower <steve.dower@python.org> added the comment:
>
> We don't formally support it yet. We probably need somebody to develop
> expertise in the emulation layer so that they can work with the Linux
> distro experts to make sure their distros are doing things properly.
>
> It has no relation at all to our Windows support (right now) - all
> versions of Python running in WSL 100% believe they are running on
> whichever Linux distro the user is running.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue45589>
> _______________________________________
>

FWIW, I don't have wslview in the Debian distro I'm currently using. It 
does have wslpath though.

Consistent detection and integration throughout CPython's standard 
library (unless we believe we need special build options too) is 
probably worth a python-dev discussion.

Understood, my mistake.

I wonder if explorer.exe or any other general purpose open command is
guaranteed to be available in all WSL distros. There’s also a consideration
to be made on WSL1 vs WSL2 (only v2 ships an actual Linux kernel).

For detection, there’re some other projects that have done this for some
time. Not sure they’re up to python-core standards, but I put an example
for the fish shell in my original description.

Might be worth looking into.

On Tue, Nov 2, 2021 at 3:28 PM Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower <steve.dower@python.org> added the comment:
>
> FWIW, I don't have wslview in the Debian distro I'm currently using. It
> does have wslpath though.
>
> Consistent detection and integration throughout CPython's standard
> library (unless we believe we need special build options too) is
> probably worth a python-dev discussion.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue45589>
> _______________________________________
>