webbrowser does not handle opens under Windows WSL properly

[guidofioravantti]

BPO	45589
Nosy	@terryjreedy, @pfmoore, @tjguk, @zware, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-10-23.17:33:22.416>
labels = ['type-feature', 'OS-windows', '3.11']
title = 'webbrowser does not handle opens under Windows WSL properly'
updated_at = <Date 2021-11-02.19:34:22.273>
user = 'https://bugs.python.org/guidofioravantti'

bugs.python.org fields:

activity = <Date 2021-11-02.19:34:22.273>
actor = 'guido.fioravantti'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2021-10-23.17:33:22.416>
creator = 'guido.fioravantti'
dependencies = []
files = []
hgrepos = []
issue_num = 45589
keywords = []
message_count = 6.0
messages = ['404896', '405482', '405534', '405535', '405537', '405539']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'zach.ware', 'steve.dower', 'guido.fioravantti']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue45589'
versions = ['Python 3.11']

[guidofioravantti]

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.

[terryjreedy]

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

[zooba]

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.

[guidofioravantti]

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\>

---

[zooba]

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.

[guidofioravantti]

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\>

---

[mhils]

There's wslview, which seems to be installed by default in most WSL distros these days. The following works well:

webbrowser.get("wslview %s").open("https://example.com")