Problem
On Linux, if you run uv venv or uv sync in a workspace while Positron is open, the new venv never shows up in the session picker or the interpreter picker. You have to reload the window to see it. A venv made with python3 -m venv usually shows up within a few seconds, but not always.
Steps to reproduce
- On Linux, open a folder that has no
.venv.
- Start any Python session.
- In the terminal, run
uv venv.
- Open the session picker.
Expected: the folder's .venv is listed.
Actual: it isn't listed, even after waiting. Reloading the window makes it appear.
Test results
A development build of Positron, run in the CI image (positron-ubuntu24, arm64, Docker Desktop), with uv 0.12.9. Each test waited 60 seconds for the venv to appear. The fourth python3 -m venv run was a video take, which waited about 25 seconds.
| Scenario |
Runs |
Venv appeared |
uv venv in a folder with no venv |
3 |
0 |
uv sync in a project folder with no venv |
3 |
0 |
python3 -m venv in a folder with no venv |
4 |
3 |
Videos
https://github.com/user-attachments/assets/52eab705-6195-4640-a0e8-377bcaf542c6
https://github.com/user-attachments/assets/8ce3c6eb-d84d-4c37-8f56-69e9d6257fe0
Why
The Python extension finds a new workspace venv through a file watcher on **/python. On Linux, that watcher never hears about .venv/bin/python when uv creates it. uv sync creates the venv the same way as uv venv.
- Linux's file watching (inotify) watches one folder at a time. Positron's watcher library, parcel watcher, starts watching each new folder after it's told the folder exists. It doesn't list what's already inside (
@parcel/watcher src/linux/InotifyBackend.cc, the IN_CREATE branch).
- uv creates
.venv, .venv/bin, and .venv/bin/python within microseconds. By the time the watcher starts watching .venv, bin and bin/python already exist, so no event is sent for either.
python3 -m venv does more setup before it creates bin/python, so the watcher is usually ready in time. In 1 of the 4 runs above it wasn't: .venv/bin, the activate scripts, and pip were reported, but not bin/python, and that venv was missed too. So this is a race that uv almost always loses, not something specific to uv.
Logging every file event the Python extension received during these tests confirms this. The python3 -m venv column is from a run where the venv appeared.
| Reported to the extension |
uv venv |
uv sync |
python3 -m venv |
.venv, .venv/pyvenv.cfg, .venv/lib |
yes |
yes |
yes |
.venv/bin |
no |
no |
yes |
.venv/bin/python |
no |
no |
yes |
**/python watcher fired |
no |
no |
yes |
Running parcel watcher on its own in a Linux container gave the same result: bin/python was reported in 1 of 16 uv venv runs, and in 5 of 5 python3 -m venv runs.
Possible fix
When a new folder or a pyvenv.cfg appears in the workspace, wait briefly, then check for a Python executable under it. pyvenv.cfg is reported for uv venvs, and every venv has one at its top level.
#16431 added something similar, but only for a venv that was deleted and then recreated (RecreatedEnvWatcher). It watches that venv's .venv and .venv/bin folders. When one is created, it checks whether .venv/bin/python exists and adds the venv. A general version would do the same for any new venv.
Problem
On Linux, if you run
uv venvoruv syncin a workspace while Positron is open, the new venv never shows up in the session picker or the interpreter picker. You have to reload the window to see it. A venv made withpython3 -m venvusually shows up within a few seconds, but not always.Steps to reproduce
.venv.uv venv.Expected: the folder's
.venvis listed.Actual: it isn't listed, even after waiting. Reloading the window makes it appear.
Test results
A development build of Positron, run in the CI image (
positron-ubuntu24, arm64, Docker Desktop), with uv 0.12.9. Each test waited 60 seconds for the venv to appear. The fourthpython3 -m venvrun was a video take, which waited about 25 seconds.uv venvin a folder with no venvuv syncin a project folder with no venvpython3 -m venvin a folder with no venvVideos
https://github.com/user-attachments/assets/52eab705-6195-4640-a0e8-377bcaf542c6
https://github.com/user-attachments/assets/8ce3c6eb-d84d-4c37-8f56-69e9d6257fe0
Why
The Python extension finds a new workspace venv through a file watcher on
**/python. On Linux, that watcher never hears about.venv/bin/pythonwhen uv creates it.uv synccreates the venv the same way asuv venv.@parcel/watchersrc/linux/InotifyBackend.cc, theIN_CREATEbranch)..venv,.venv/bin, and.venv/bin/pythonwithin microseconds. By the time the watcher starts watching.venv,binandbin/pythonalready exist, so no event is sent for either.python3 -m venvdoes more setup before it createsbin/python, so the watcher is usually ready in time. In 1 of the 4 runs above it wasn't:.venv/bin, theactivatescripts, andpipwere reported, but notbin/python, and that venv was missed too. So this is a race that uv almost always loses, not something specific to uv.Logging every file event the Python extension received during these tests confirms this. The
python3 -m venvcolumn is from a run where the venv appeared.uv venvuv syncpython3 -m venv.venv,.venv/pyvenv.cfg,.venv/lib.venv/bin.venv/bin/python**/pythonwatcher firedRunning parcel watcher on its own in a Linux container gave the same result:
bin/pythonwas reported in 1 of 16uv venvruns, and in 5 of 5python3 -m venvruns.Possible fix
When a new folder or a
pyvenv.cfgappears in the workspace, wait briefly, then check for a Python executable under it.pyvenv.cfgis reported for uv venvs, and every venv has one at its top level.#16431 added something similar, but only for a venv that was deleted and then recreated (
RecreatedEnvWatcher). It watches that venv's.venvand.venv/binfolders. When one is created, it checks whether.venv/bin/pythonexists and adds the venv. A general version would do the same for any new venv.