microsoft / microsoft/vscode-python-environments

Jupyter kernel startup delayed 30s+ with pixi environment on WSL2 (continuation of locked #1407)

Ouverte
#1,672 0 commentaires 2 réactions 1 personne assignée Voir sur GitHub

@eleanorjboyd y travaille déjà.

Depuis le 5/8/2026.

Langage dominant
TypeScript
Étoiles
138
Forks
62
Merge moyen
1 j 4 h
PR mergées (30 j)
35

Description

Opening this as a new issue since #1407 ("Jupyter kernel startup delayed 30s when extension is installed (pixi environment)") is locked and can no longer receive comments, despite being closed only due to staleness rather than resolution — multiple users in that thread confirmed the bug persisted across many extension versions right up until the lock. I'm hitting the identical issue on a platform not yet represented there (WSL2; prior reports were macOS/Windows), so filing this to keep it tracked.

**Environment:**
- VS Code: 1.130.0 (WSL, desktop)
- `ms-python.python`: 2026.4.0
- `ms-python.vscode-python-envs`: 1.36.0
- `ms-toolsai.jupyter`: 2025.9.1
- Platform: linux x64 (WSL2)
- Package manager: pixi

**Symptoms match #1407 exactly:**
```
10:04:29.821 [warn] Failed to get activated env vars for ~/project/.pixi/envs/default/bin/python in 35151ms
```

In my case it compounds further — the kernel gets disposed and reselected between different interpreters multiple times in a row (seemingly automatic, not user-initiated), and *each* reselection re-triggers the same ~30-35s stall, making it look like an indefinite hang rather than a one-time delay. The Python Environments output channel shows the same conda-detection fallback (`pet_conda::package: Unable to find conda package Python in ".../pixi/envs/default", trying slower approach`) re-firing repeatedly against the identical path over the course of hours in a single session — I have logs showing the same non-conda path being re-probed via this fallback continuously from session start to +17,800 seconds later, rather than the negative result being cached after the first check.

I confirmed this isn't pixi/shell being slow — `pixi shell-hook` for the same environment completes in under a second when run directly. This lines up with the root cause identified by @korsbakken in #1407: the underlying command uses `pixi shell` (which starts an interactive shell that never returns on its own) rather than `pixi run`, so the `&&`-chained follow-up commands never execute and the whole thing stalls until timeout.

**Workaround (confirmed by multiple users in #1407):** setting `"python.useEnvironmentsExtension": false`, or disabling `ms-python.vscode-python-envs` entirely.

Related: microsoft/vscode-python-environments#1407, renan-r-santos/pixi-code#21, renan-r-santos/pixi-code#28, renan-r-santos/pixi-code#43

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.