Installer Node, Python et Go dans WSL : environnements dev propres sans le bazar Windows

Les règles : garder Windows propre, garder WSL honnête

Un environnement dev propre consiste surtout à refuser le « je l’installe vite fait ». Vous pouvez évidemment installer Node sur Windows, Python sur Windows, Go sur Windows,
puis les réinstaller dans WSL, puis vous demander pourquoi vos outils utilisent aléatoirement le mauvais binaire. Ce n’est pas un rite de passage. C’est un incident évitable.

Mon choix par défaut et sans compromis :

• Installez les runtimes dans WSL, pas sur Windows. Utilisez Windows uniquement pour les éditeurs/terminaux et les outils GUI optionnels.
• Utilisez des gestionnaires de versions (nvm, pyenv) sauf si vous avez un monorepo contrôlé avec toolchains figés intégrés dans des conteneurs.
• Gardez le code source et les caches de dépendances dans le système de fichiers Linux (à l’intérieur de la distro WSL), pas sous /mnt/c.
• Évitez d’importer le PATH Windows dans le PATH de WSL sauf si vous avez une raison précise. L’interopérabilité est un scalpel, pas un régime.
• Automatisez l’installation avec un script bootstrap et des dotfiles. Si votre environnement ne peut pas être reconstruit, ce n’est pas un environnement ; c’est un animal de compagnie.

Exactement une citation, parce qu’elle vaut l’encre. L’idée paraphrasée de Gene Kim est : la fiabilité vient des systèmes et des boucles de rétroaction, pas des héros.
La configuration WSL est la même : des valeurs par défaut ennuyeuses battent des hacks astucieux.

Blague #1 : La façon la plus rapide d’apprendre l’ordre de priorité du PATH est de casser l’ordre de priorité du PATH.
La deuxième façon la plus rapide est de lire le reste de cet article.

Faits et historique que vous pouvez exploiter

Quelques faits brefs qui expliquent pourquoi WSL se comporte comme il le fait — et pourquoi le chemin « facile » devient souvent coûteux.

1. WSL 1 et WSL 2 sont des bêtes différentes. WSL 2 utilise un noyau Linux réel dans une VM légère ; WSL 1 traduisait les appels système Linux. Les performances et la sémantique diffèrent.
2. Le réseau de WSL 2 est NATé par défaut. Localhost fonctionne généralement, mais certains proxies d’entreprise, VPN et hypothèses d’exposition de ports vous trahiront.
3. L’accès cross-filesystem est asymétrique. L’accès au système de fichiers Linux depuis WSL est rapide ; accéder aux fichiers Windows sous /mnt/c est plus lent, surtout pour de nombreux petits fichiers (bonjour, node_modules).
4. Les outils Node ont gagné en complexité. npm est devenu une plateforme ; Yarn et pnpm ont lutté pour la faveur ; Corepack est apparu pour standardiser les versions des gestionnaires de paquets.
5. L’écosystème Python est encore une zone de guerre. Wheels vs builds source, bibliothèques système et environnements virtuels créent des modes de défaillance qui ressemblent à « Python est cassé » mais sont en réalité « vos entrées de build sont incohérentes ».
6. Go a volontairement réduit la complexité d’environnement. Les modules (Go 1.11+) ont déplacé la gestion des dépendances hors des workflows centrés sur GOPATH, mais GOPATH compte encore pour les caches et les outils anciens.
7. Les paquets d’Ubuntu privilégient la stabilité à la fraîcheur. Les paquets apt peuvent être en retard sur les versions des langages. Les gestionnaires de versions existent parce que « latest » et « secure » ne sont pas synonymes.
8. Les images Windows d’entreprise sont engagées. Elles livrent des lanceurs Python, un Git ancien et des agents de sécurité qui accrochent les E/S fichiers. Mélanger runtimes entre Windows et WSL rend le débogage deux fois plus amusant et moitié moins utile.

Fondation : choisissez votre distro, fixez des limites et vérifiez la santé de WSL

Choisissez une distro WSL par « persona ». Pour la plupart, c’est une seule distro Ubuntu pour le travail quotidien. Plusieurs distros sont acceptables quand vous avez besoin d’isolation
(par ex., une pour l’archéologie Python 2 legacy, une pour l’outillage moderne), mais ne créez pas dix distros parce que vous n’arrivez pas à choisir entre des shells.

Version WSL et sanity de la distro

Avant d’installer des toolchains, confirmez que vous êtes sur WSL 2 et que votre distro est saine. Si la base est bancale, chaque étape d’installation devient du folklore.

Limite #1 : arrêtez d’hériter automatiquement du PATH Windows sauf si c’est volontaire

La casse la plus sournoise arrive quand WSL « aide » en incluant les chemins Windows. Soudain votre python dans WSL pointe vers un exécutable Windows,
qui tente ensuite de lire des chemins Linux et échoue de façons créatives.

Désactivez cela en éditant /etc/wsl.conf à l’intérieur de la distro puis en redémarrant WSL.

Limite #2 : traitez le système de fichiers WSL comme votre disque de dev

Placez les repos sous ~ (ou un autre chemin Linux), pas sous /mnt/c/Users/.... Le second va vous brûler sur les performances et les cas limites des outils.
Si vous devez travailler sur des fichiers Windows (conformité, partages), isolez ce flux et acceptez qu’il soit plus lent.

Emplacement du système de fichiers : où vit votre code décide de votre rapidité

Vos toolchains ne sont pas lents ; votre chemin de stockage est lent. Node et Python sont particulièrement sensibles car ils créent et lisent des milliers de petits fichiers.
Si ceux-ci résident sous /mnt/c, chaque opération de fichier prend le chemin long via l’interop.

La règle est simple :

• Code + dépendances dans le système de fichiers ext4 de WSL (typiquement sous /home) pour la vitesse.
• Chemins montés Windows pour un échange occasionnel de fichiers, pas pour les builds.

Quand quelqu’un dit « WSL est lent », je pose une question : « Où est le repo ? » La plupart du temps, c’est tout le mystère.

Node.js dans WSL (nvm, corepack et éviter le chaos global)

Installez Node dans WSL en utilisant nvm. Je me moque qu’apt ait nodejs. Je me moque que Windows ait déjà Node. Vous voulez des versions par utilisateur, rapides et reproductibles,
qui ne vont pas rentrer en collision avec les paquets système ou l’outillage d’entreprise.

Politique de versions qui n’engendre pas la fatigue des pages d’incident

• Utilisez Active LTS pour la plupart des équipes.
• Utilisez current seulement quand vous validez à l’avance, pas parce que vous vous sentez chanceux.
• Verrouillez la major/minor de Node dans .nvmrc à la racine du repo. C’est votre contrat.

Gestionnaires de paquets : laissez Corepack faire son boulot

Les setups Node modernes utilisent souvent Yarn ou pnpm. Corepack est livré avec Node et peut installer et verrouiller la version du gestionnaire de paquets déclarée par le projet.
Cela réduit les « ça marche sur ma machine » parce que « ma machine » avait Yarn 1 alors que le CI avait Yarn 3.

Les installations npm globales sont acceptables pour un petit ensemble d’outils (linters, générateurs) mais privilégiez les binaires locaux au projet et npx ou les scripts.
Les installations globales deviennent un tiroir à bazar partagé sans étiquettes.

Python dans WSL (pyenv, venv et dépendances compilées)

Python est le runtime qui punira les intentions vagues. Installez avec pyenv quand vous avez besoin de plusieurs versions (vous en avez besoin), et utilisez venv
par projet. N’installez pas des paquets pip au hasard globalement puis ne vous étonnez pas qu’un projet sabote un autre.

Dépendances système : la partie que tout le monde oublie

Beaucoup de paquets Python incluent des extensions natives (cryptography, numpy, lxml). Les wheels existent souvent, mais pas toujours pour votre version Python ou votre architecture.
Quand pip compile depuis la source, vous avez besoin des headers système et des compilateurs. C’est pourquoi le « pip install simple » devient parfois une installation de toolchain C.
C’est normal. Ce n’est juste pas plaisant.

Deux règles qui éliminent la plupart des drames Python

• Utilisez toujours un venv et gardez-le dans le projet ou dans un répertoire dédié.
• Verrouillez les dépendances avec une approche de lock adaptée à votre organisation (requirements.txt avec hashes, pip-tools, poetry, etc.). Le mécanisme importe moins que la discipline.

Go dans WSL (GOVERSION, GOPATH et hygiène des modules)

Go est le moins dramatique des trois, ce qui pousse à la complaisance et à des pratiques étranges comme dépaqueter des tarballs manuellement dans des répertoires aléatoires.
Installez Go dans WSL à un emplacement prévisible et gardez vos variables d’environnement ennuyeuses.

Vision axée modules

Si vous construisez du Go moderne, utilisez les modules. Mettez le code où vous voulez (dans votre home est correct), et laissez go env vous dire ce qui compte.
GOPATH existe toujours et influence les caches et les outils anciens, mais ce n’est plus l’endroit où votre code doit obligatoirement vivre.

Stratégie de version Go

Si votre organisation déploie plusieurs services Go, vous aurez tôt ou tard besoin de plusieurs versions de Go. Vous pouvez utiliser un gestionnaire de versions Go, ou standardiser par trimestre.
Ce que vous ne devriez pas faire, c’est « whatever Go était installé sur le laptop ce jour-là ».

Interop sans douleur : PATH, Git, SSH et VS Code

La configuration la plus propre est : langages dans WSL, éditeur sur Windows, et une couche d’interop minimale entre les deux. L’intégration WSL de VS Code est populaire parce qu’elle
ne prétend pas que la frontière n’existe pas — elle la rend juste moins pénible.

Git : choisissez un côté et soyez cohérent

Utilisez Git dans WSL pour les repos stockés dans WSL. Si vous utilisez Git Windows sur un repo dans WSL, vous invitez des bizarreries de fins de ligne et des surprises de permissions.
Si vous utilisez Git WSL sur un repo sous /mnt/c, vous aurez probablement des problèmes de performance et une confusion occasionnelle des métadonnées.

Clés SSH : ne les copiez pas partout sans réfléchir

Stockez les clés dans WSL (~/.ssh) et protégez-les avec les permissions adéquates. Si vous devez utiliser des clés gérées par Windows, soyez explicite sur la stratégie d’agent.
La catégorie « ça fonctionnait hier » des problèmes SSH provient souvent d’une confusion d’agent à travers la frontière.

Blague #2 : Rien ne vieillit plus vite qu’une clé SSH collée dans un chat « juste pour une minute ».

Trois mini-histoires d’entreprise (comment les équipes cassent ça)

Incident : la mauvaise hypothèse (héritage du PATH et le Python fantôme)

Une équipe a migré un monorepo Node + Python vers WSL pour se rapprocher du Linux de production. Les gens étaient contents pendant environ une semaine.
Puis le CI a commencé à échouer pour un seul développeur, avec des erreurs d’outillage Python qui semblaient liées à de mauvaises dépendances. Tout le monde a fait la danse habituelle :
supprimer le venv, réinstaller, vider les caches, jurer doucement.

La cause racine n’était pas le repo. C’était une hypothèse : « Si je suis dans WSL, python est Python Linux. » Sur cette machine, WSL héritait du PATH Windows,
et python.exe de Windows était appelé en premier. Ça ne ratait pas toujours ; ça ratait quand des scripts passaient des chemins Linux ou comptaient sur des bibliothèques spécifiques à Linux.
Les messages d’erreur étaient trompeurs parce que le mauvais interpréteur s’exécutait.

La correction fut ennuyeuse : désactiver l’injection du PATH Windows dans /etc/wsl.conf, redémarrer WSL, et vérifier l’identité de l’interpréteur avec which python
et python -c. Après cela, leur documentation d’installation incluait explicitement « prouvez que votre Python est un Python Linux » comme étape requise.

La leçon : quand une panne est spécifique à une machine et incohérente, suspectez la frontière — PATH, emplacement du système de fichiers, paramètres de proxy — avant de soupçonner les dépendances.
Les dépendances sont déterministes ; votre environnement, souvent non.

Optimisation qui s’est retournée contre eux (déplacer les repos sous /mnt/c pour « simplifier les backups »)

Une autre organisation a décidé qu’il serait « plus propre » que tout le code source vive sous le profil utilisateur Windows pour être inclus dans les sauvegardes d’entreprise et les scans DLP.
Leur distro WSL était considérée comme jetable. Ça sonnait raisonnable en réunion.

La première plainte fut la lenteur des installations : npm ci qui durait une éternité. Puis les builds Go ont commencé à traîner. La création de venv Python est devenue lente.
Les ingénieurs ont commencé à revenir aux outils natifs Windows « pour la vitesse », ce qui a réintroduit le même bazar « deux environnements » qu’ils tentaient d’éviter.

Les agents de sécurité sur Windows scannaient les opérations fichiers, multipliant la douleur pour les workloads à « nombreux petits fichiers ». L’arbre de dépendances Node est essentiellement
un banc d’essai pour le surcoût du système de fichiers, et il a échoué bruyamment. L’équipe a essayé d’optimiser en excluant des répertoires du scan, mais les exceptions de politique étaient lentes,
et les exclusions ne couvraient pas tous les chemins.

Ils ont finalement inversé le modèle : les repos et les répertoires de dépendances vivent dans le système de fichiers de WSL pour les performances ; la sauvegarde est gérée par des pushes git distants et,
au besoin, par l’export d’artefacts. Les préoccupations DLP ont été traitées en contrôlant ce qui peut être copié hors de WSL plutôt qu’en punissant chaque lecture/écriture.

La leçon : optimiser pour la gouvernance en déplaçant les workloads chauds de build sur le système de fichiers Windows, c’est comme mettre votre base de données sur du stockage réseau « pour la commodité ».
Ça fonctionne. Ça sera aussi lent. Et alors les gens vont contourner ça de façons que vous ne contrôlez pas.

Pratique ennuyeuse mais correcte qui a sauvé la mise (verrouiller les toolchains et les vérifier)

Une équipe plateforme supportait des dizaines de services Node, Python et Go. Ils ne voulaient pas de laptops snowflake. Ils ont écrit un script bootstrap qui :
installait les paquets de base, configurait les limites WSL, installait nvm/pyenv, et définissait des versions par défaut. Ils ont aussi ajouté une étape « vérifier » qui affichait les versions et les chemins clés.

Ce n’était pas tape-à-l’œil. Ce n’était pas un outil de provisioning sophistiqué. C’était un script shell et une checklist. Il imposait aussi des sorties standard : le node, python,
pip et go de chacun étaient vérifiés de la même manière. Ça signifiait que les tickets de support commençaient par des faits, pas des impressions.

Quand une nouvelle image de portable corporate est sortie, elle a silencieusement changé l’ordre du PATH Windows et introduit un shim Python Windows qui a confondu certains utilisateurs WSL — sur certaines machines.
La vérification du bootstrap l’a détecté immédiatement parce que la sortie ne correspondait pas aux motifs attendus. Au lieu d’un mois de problèmes intermittents, ce fut une correction en un jour :
mettre à jour la guidance sur /etc/wsl.conf et relancer l’étape de vérification.

La leçon : la pratique ennuyeuse est « verrouillez les versions et vérifiez l’identité ». Pas une fois, mais à chaque reconstruction. C’est terne jusqu’à ce que ça vous sauve, puis c’est votre préféré.

Playbook de diagnostic rapide

Quand « Node/Python/Go dans WSL est cassé » arrive sur votre bureau, n’installez pas tout de suite. Vous allez détruire les preuves et perdre du temps.
Diagnostiquez dans cet ordre pour trouver le goulot rapidement.

Premier : confirmez la frontière (version WSL, PATH, emplacement du système de fichiers)

• Est-ce WSL 2 ?
• Le repo est-il dans le système de fichiers Linux ou sous /mnt/c ?
• WSL hérite-t-il du PATH Windows ? Des binaires Windows masquent-ils les binaires Linux ?

Deuxième : confirmez l’identité du toolchain (quel binaire, quelle version, quelle méthode d’installation)

• Pour Node : which node, node -v, nvm current
• Pour Python : which python, python -V, python -c "import sys; print(sys.executable)"
• Pour Go : which go, go version, go env

Troisième : confirmez les contraintes de performance (I/O, CPU, mémoire, interaction antivirus)

• Si les installs/builds sont lents : vérifiez si vous opérez sur /mnt/c.
• En cas de blocages aléatoires : vérifiez l’espace disque libre et la pression mémoire dans WSL.
• Si les récupérations réseau échouent : vérifiez les paramètres proxy et la résolution DNS dans WSL.

Quatrième : seulement alors réinstallez

Réinstaller sans savoir ce qui a foiré, c’est comment on se retrouve avec trois installations cassées au lieu d’une.

Erreurs courantes : symptômes → cause racine → correction

1) « python pointe vers python.exe »

Symptômes : python s’exécute mais ne peut pas importer des modules Linux ; les chemins ressemblent à C:\... ; le venv se comporte étrangement.

Cause racine : WSL a hérité du PATH Windows ; Python Windows est en première priorité.

Correction : Désactivez l’ajout du PATH dans /etc/wsl.conf, redémarrez WSL, vérifiez avec which python et file $(which python).

2) « npm install prend une éternité »

Symptômes : npm ci ou pnpm install est beaucoup plus lent que chez les collègues ; forte utilisation CPU dans les processus de sécurité Windows.

Cause racine : Repo ou node_modules sous /mnt/c ; système de fichiers Windows + surcharge de scan pour les petits fichiers.

Correction : Déplacez le repo dans le système de fichiers WSL (~/src), réinstallez les dépendances, gardez l’accès Windows uniquement pour l’édition.

3) « pyenv install échoue avec headers manquants »

Symptômes : Erreurs de build mentionnant zlib, openssl, readline ou ffi.

Cause racine : Dépendances de build manquantes pour compiler Python.

Correction : Installez les paquets requis via apt (compilateur, headers dev), puis retentez pyenv install.

4) « go get fonctionne, mais les builds échouent sur le CI »

Symptômes : Build local réussi ; CI ou build d’un collègue échoue ; versions de modules différentes.

Cause racine : Versions de modules non verrouillées/commitées ; dérive des go.mod/go.sum.

Correction : Exécutez go mod tidy, commitez go.sum, et définissez une version minimale de Go dans go.mod.

5) « Permission denied dans le repo »

Symptômes : Git ne peut pas écrire ; outils ne peuvent pas créer de fichiers ; décalages étranges UID/GID.

Cause racine : Travail dans le système de fichiers monté Windows avec incompatibilité des métadonnées de permissions ; parfois de mauvaises options de montage.

Correction : Déplacez le repo dans le système de fichiers WSL ; si vous devez utiliser /mnt/c, ajustez les options de montage et acceptez les limitations.

6) « Le terminal VS Code affiche un Node, les tasks en utilisent un autre »

Symptômes : Le terminal affiche Node 20 ; les tâches/scripts de build se comportent comme Node 18 ; résultats incohérents.

Cause racine : Contexte mixte : VS Code Windows lance des tâches dans un shell Windows vs WSL ; ou le PATH diffère entre shells de connexion et non-connexion.

Correction : Assurez-vous d’être dans une fenêtre Remote WSL ; assurez-vous que l’initialisation du shell charge nvm/pyenv pour les shells non interactifs, ou configurez explicitement les tâches.

Tâches pratiques (commandes + sorties + décisions)

Voici des vérifications réelles que j’exécute. Chacune contient : une commande, ce que signifie la sortie, et la décision à en tirer.
Exécutez-les dans WSL sauf indication contraire.

Task 1: Confirm WSL version and distros (from Windows)

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Meaning: Your primary distro is Ubuntu-22.04 and it’s WSL 2.

Decision: If VERSION is 1, convert it or install a WSL 2 distro. Don’t build modern toolchains on WSL 1 unless you enjoy edge cases.

Task 2: Check kernel and distro basics

cr0x@server:~$ uname -a
Linux cr0x-laptop 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 12 20:38:48 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Meaning: You’re on the WSL2 kernel line; architecture is x86_64.

Decision: If you see unexpected architecture (e.g., arm64), ensure your language builds and binaries match.

Task 3: Detect Windows PATH leakage

cr0x@server:~$ echo "$PATH" | tr ':' '\n' | head -n 10
/home/cr0x/.nvm/versions/node/v20.11.1/bin
/home/cr0x/.pyenv/shims
/home/cr0x/.pyenv/bin
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Meaning: PATH starts with Linux user toolchains; no obvious /mnt/c/Windows entries in the first lines.

Decision: If you see many /mnt/c entries, disable PATH append in /etc/wsl.conf and restart WSL.

Task 4: Verify where Node comes from

cr0x@server:~$ which node
/home/cr0x/.nvm/versions/node/v20.11.1/bin/node

Meaning: Node is provided by nvm in your home directory.

Decision: If which node points to /usr/bin/node, you’re using apt’s Node. Decide if that’s acceptable; usually it’s not for multi-version work.

Task 5: Confirm Node and npm are coherent

cr0x@server:~$ node -v && npm -v
v20.11.1
10.2.4

Meaning: Node and npm versions are aligned for that Node release.

Decision: If npm is unexpectedly old/new, you may have PATH shadowing or a partial install.

Task 6: Check Corepack status (Yarn/pnpm control plane)

cr0x@server:~$ corepack --version
0.24.1

Meaning: Corepack exists and can manage Yarn/pnpm versions.

Decision: If missing, you’re likely on an older Node or a custom build; decide whether to upgrade Node or manage package managers manually.

Task 7: Verify Python identity and executable path

cr0x@server:~$ which python
/home/cr0x/.pyenv/shims/python

Meaning: Python is controlled by pyenv shims (good for multi-version).

Decision: If it points to /mnt/c/... or ends in .exe, you’re running Windows Python inside WSL. Fix PATH leakage.

Task 8: Confirm Python version and where it runs from

cr0x@server:~$ python -V
Python 3.12.2

cr0x@server:~$ python -c "import sys; print(sys.executable)"
/home/cr0x/.pyenv/versions/3.12.2/bin/python

Meaning: You’re running the pyenv-installed interpreter.

Decision: If sys.executable points somewhere surprising, stop and fix interpreter selection before touching dependencies.

Task 9: Create and validate a venv (proves pip isolation)

cr0x@server:~$ python -m venv .venv
cr0x@server:~$ source .venv/bin/activate
(.venv) cr0x@server:~$ which python
/home/cr0x/.venv/bin/python

Meaning: Your shell is using the venv interpreter; pip installs will go into the venv.

Decision: If which python doesn’t change after activation, your shell init is broken or you’re not activating correctly.

Task 10: Verify Go installation and environment

cr0x@server:~$ which go
/usr/local/go/bin/go

cr0x@server:~$ go version
go version go1.22.1 linux/amd64

Meaning: Go is installed in a standard location and reports the correct OS/arch.

Decision: If it reports windows/amd64, you somehow called Windows Go from WSL. That’s a boundary violation.

Task 11: Confirm Go module mode and key paths

cr0x@server:~$ go env GOPATH GOMOD GOCACHE
/home/cr0x/go
/home/cr0x/src/myservice/go.mod
/home/cr0x/.cache/go-build

Meaning: GOPATH is in your home; modules are active (GOMOD points to a go.mod); caches are in Linux space.

Decision: If GOMOD is empty inside a module repo, you’re not in the module directory or GO111MODULE behavior is odd; fix before debugging dependencies.

Task 12: Detect “repo is on /mnt/c” (performance red flag)

cr0x@server:~$ pwd
/mnt/c/Users/cr0x/source/myapp

Meaning: You’re building from the Windows filesystem mount.

Decision: If this repo contains Node or Python dependencies, move it to ~/src in WSL. Expect big speedups.

Task 13: Measure basic disk space (mysterious install failures love full disks)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        251G  198G   41G  83% /

Meaning: You have ~41G free in the distro filesystem.

Decision: If you’re near 100%, stop. Clean caches before blaming package managers.

Task 14: Check memory pressure (random build kills and slowdowns)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       5.6Gi       410Mi       112Mi       1.8Gi       1.7Gi
Swap:          2.0Gi       1.4Gi       640Mi

Meaning: Available memory is low, swap is active.

Decision: Expect slow builds. Close memory-heavy apps, tune WSL memory limits, or reduce parallelism for installs/tests.

Task 15: Check DNS and outbound connectivity (package fetch failures)

cr0x@server:~$ getent hosts pypi.org
151.101.64.223  pypi.org
151.101.128.223 pypi.org
151.101.192.223 pypi.org
151.101.0.223   pypi.org

Meaning: DNS resolution works from inside WSL.

Decision: If resolution fails, troubleshoot WSL DNS/proxy before touching language installers.

Listes de contrôle / plan étape par étape

Plan A : installation propre et reproductible (recommandé)

1. Confirmez WSL 2 et choisissez une distro.
   Utilisez wsl.exe -l -v. Si vous voyez WSL 1, corrigez cela d’abord.
2. Mettez à jour les paquets de base.
   Exécutez apt update/upgrade et installez les outils de build essentiels. Cela évite les « pip a essayé de compiler quelque chose et a échoué » plus tard.
3. Définissez des limites dans /etc/wsl.conf.
   Désactivez l’injection du PATH Windows sauf si vous avez un besoin spécifique.
4. Créez un espace de travail natif Linux.
   Faites ~/src, clonez les repos là et arrêtez de développer sous /mnt/c.
5. Installez nvm, puis Node LTS.
   Ajoutez .nvmrc par repo. Préférez corepack pour verrouiller Yarn/pnpm.
6. Installez pyenv, puis les versions Python nécessaires.
   Définissez un default global et une version locale par repo quand nécessaire.
7. Utilisez venv par projet.
   Créez .venv, activez-le, puis installez les dépendances.
8. Installez Go dans un chemin stable.
   Ajoutez Go au PATH, vérifiez go env.
9. Exécutez les tâches de vérification.
   Vérifiez which et les versions pour node/python/go, et vérifiez l’emplacement du repo.
10. Automatisez.
    Mettez ces étapes dans un script bootstrap et exigez-le pour l’onboarding.

Plan B : quand vous êtes forcé de travailler sous /mnt/c (acceptable mais plus lent)

1. Gardez quand même les runtimes dans WSL. N’installez pas des runtimes Windows parallèles « pour accélérer ».
2. Gardez les répertoires lourds en dépendances en dehors de /mnt/c si possible (certains outils permettent de configurer caches et sorties de build).
3. Attendez-vous à des installations Node lentes. Planifiez : utilisez des lockfiles, évitez les réinstallations propres répétées, et ne jugez pas WSL sur ce mode.
4. Soyez explicite sur les fins de ligne et les bits exécutables ; les systèmes de fichiers Windows ne préservent pas naturellement les sémantiques Linux.

FAQ

Dois‑je installer Node/Python/Go aussi sur Windows ?

En général non. Installez-les dans WSL. Les installer sur Windows crée de l’ambiguïté : éditeurs, terminaux et scripts peuvent choisir des runtimes différents.
Si vous avez besoin de builds natifs Windows pour un produit spécifique, isolez ce workflow et documentez‑le.

WSL 2 est‑il toujours meilleur que WSL 1 pour le dev ?

Pour la plupart des stacks modernes, oui. WSL 2 est plus proche du comportement Linux réel et meilleur pour les conteneurs et la compatibilité des outils.
WSL 1 peut être utile pour certains patterns d’accès au système de fichiers, mais ce n’est pas le choix par défaut pour des toolchains propres.

Pourquoi Node est‑il tellement plus lent dans certains setups ?

Parce que les workloads Node stressent le système de fichiers : beaucoup de petits fichiers, opérations fréquentes de métadonnées. Si votre repo est sur /mnt/c,
vous payez le surcoût d’interop plus tout ce que fait l’outil de sécurité Windows.

Puis‑je utiliser apt pour installer Node et Python au lieu des gestionnaires de versions ?

Vous pouvez, mais vous échangez la simplicité d’aujourd’hui contre de la douleur plus tard quand les versions divergent entre projets. apt convient si vous avez une version stable unique
fournie par la distro. La plupart des équipes ont besoin de plusieurs versions. Utilisez nvm et pyenv.

Que penser de Conda pour Python ?

Conda peut bien fonctionner, surtout pour les stacks scientifiques. En entreprise, il peut aussi introduire son propre univers de dépendances et une empreinte disque importante.
Si votre organisation standardise déjà sur Conda, utilisez‑le. Sinon, pyenv + venv est généralement plus simple et plus natif Linux.

Où dois‑je stocker mes dépôts Git ?

Dans le système de fichiers Linux de WSL (par ex. ~/src) pour les performances et les sémantiques Linux correctes. Utilisez les chemins Windows pour un partage occasionnel de fichiers,
pas pour des builds lourds en dépendances.

Comment garder mon environnement reproductible au sein d’une équipe ?

Verrouillez les versions des outils dans le repo (.nvmrc, fichiers de version Python, go.mod), commitez les lockfiles, et fournissez un script bootstrap qui installe
les gestionnaires de versions et les paquets requis. Ajoutez une étape de vérification qui affiche chemins et versions.

Ai‑je besoin de Docker si j’utilise WSL ?

Pas toujours. WSL vous donne un userland Linux adapté au développement. Docker ajoute de l’isolation runtime et de la parité de production pour des services.
Beaucoup d’équipes utilisent les deux : WSL pour le shell développeur, Docker pour les services et dépendances.

Quelle est la façon la plus sûre de gérer les clés SSH avec WSL ?

Gardez les clés dans WSL sous ~/.ssh, utilisez des permissions strictes, et utilisez un agent SSH dans WSL quand c’est possible.
Évitez de copier les clés entre Windows et WSL sans précaution. Si la politique d’entreprise exige un agent Windows, documentez explicitement l’intégration.

Pourquoi ai‑je des comportements différents entre sessions de terminal ?

L’initialisation du shell diffère entre shells interactifs et non interactifs, login vs non‑login, et entre applications terminal. Si l’initialisation de nvm/pyenv n’est présente que dans un fichier,
vos outils peuvent disparaître dans un autre contexte. Standardisez votre init de shell.

Prochaines étapes pour rester propre

Si vous voulez un environnement WSL qui ne pourrit pas :

1. Déplacez les repos actifs dans ~/src à l’intérieur de WSL et relancez les installations. Cela résout à lui seul un nombre surprenant de plaintes « WSL est lent ».
2. Désactivez l’héritage du PATH Windows dans WSL sauf si vous l’avez justifié par un vrai besoin.
3. Adoptez des gestionnaires de versions : nvm pour Node, pyenv pour Python, et une stratégie Go cohérente. Verrouillez les versions par repo.
4. Écrivez un script bootstrap et un script de vérification. Faites de « afficher versions et chemins » la première étape du débogage, pas la dernière.
5. Quand quelque chose casse, suivez l’ordre de diagnostic : frontière → identité → performance → réinstaller. Ne devinez pas.

Le but n’est pas de vénérer la propreté. C’est de faire en sorte que votre portable se comporte comme un petit système de production prévisible : entrées contrôlées, frontières claires,
et pannes explicables plutôt que mystiques.