Instalar Node, Python y Go en WSL: entornos de desarrollo limpios sin ensuciar Windows

Las reglas: mantener Windows limpio, mantener WSL honesto

Un entorno de desarrollo limpio tiene más que ver con negarse a “instalarlo rápido y ya está.” Puedes absolutamente instalar Node en Windows, Python en Windows, Go en Windows,
luego instalarlos de nuevo en WSL, y después preguntarte por qué tus herramientas usan binarios equivocados al azar. Eso no es un rito de iniciación. Es un incidente prevenible.

Mi predeterminado con opinión:

• Instala los runtimes dentro de WSL, no en Windows. Usa Windows solo para editores/terminales y herramientas GUI opcionales.
• Usa gestores de versiones (nvm, pyenv) a menos que tengas un monorepo controlado con toolchains fijados dentro de contenedores.
• Mantén el código fuente y las cachés de dependencias en el sistema de archivos Linux (dentro de la distro WSL), no bajo /mnt/c.
• Mantén el PATH de Windows fuera del PATH de WSL a menos que tengas una razón específica. La interoperabilidad es un bisturí, no una dieta.
• Automatiza la configuración con un script bootstrap y dotfiles. Si tu entorno no puede reconstruirse, no es un entorno; es una mascota.

Exactamente una cita, porque vale la tinta. La idea (parafraseada) de Gene Kim es: la fiabilidad viene de sistemas y bucles de retroalimentación, no de héroes.
Configurar WSL es lo mismo: los valores por defecto aburridos superan a los trucos ingeniosos.

Broma #1: La forma más rápida de aprender sobre la precedencia de PATH es romper la precedencia de PATH.
La segunda más rápida es leer el resto de este artículo.

Hechos e historial que puedes usar

Algunos hechos breves que explican por qué WSL se comporta como lo hace—y por qué la ruta “fácil” de instalación suele acabar siendo la cara.

1. WSL 1 y WSL 2 son bestias diferentes. WSL 2 usa un kernel Linux real en una VM ligera; WSL 1 traducía llamadas al sistema Linux. El rendimiento y la semántica difieren.
2. La red en WSL 2 está NATeada por defecto. Localhost suele funcionar, pero algunos proxies corporativos, VPNs y suposiciones sobre exposición de puertos te traicionarán.
3. El acceso entre sistemas de archivos es asimétrico. El acceso al sistema de archivos Linux desde WSL es rápido; acceder a archivos de Windows bajo /mnt/c es más lento, especialmente para muchos archivos pequeños (hola, node_modules).
4. Las herramientas de Node se han ido complicando con el tiempo. npm se convirtió en plataforma; Yarn y pnpm compitieron por cuota; Corepack apareció para estandarizar versiones de gestores de paquetes.
5. El empaquetado de Python sigue siendo un campo de batalla. Wheels vs compilaciones desde código fuente, librerías del sistema y entornos virtuales crean modos de fallo que parecen “Python está roto” pero en realidad son “tus entradas de compilación son inconsistentes”.
6. Go redujo deliberadamente la complejidad del entorno. Los módulos (Go 1.11+) movieron la gestión de dependencias fuera del flujo centrado en GOPATH, pero GOPATH sigue importando para cachés y herramientas antiguas.
7. Los paquetes de Ubuntu sacrifican novedad por estabilidad. Los paquetes apt pueden quedarse atrás respecto a las versiones de lenguajes. Los gestores de versiones existen porque “última” y “segura” no son sinónimos.
8. Las imágenes corporativas de Windows son opinadas. Vienen con launchers de Python, Git antiguo y agentes de seguridad que enganchan la E/S de archivos. Mezclar runtimes entre Windows y WSL hace que depurar sea el doble de divertido y la mitad de útil.

Fundamentos: elige tu distro, marca límites y verifica la salud de WSL

Elige una distro WSL por “personalidad”. Para la mayoría eso es una distro Ubuntu para el trabajo diario. Varias distros están bien cuando necesitas aislamiento
(por ejemplo, una para arqueología de Python 2 y otra para herramientas modernas), pero no crees diez distros porque no puedes decidir entre shells.

Sanidad de versión de WSL y de la distro

Antes de instalar cualquier toolchain de lenguaje, confirma que estás en WSL 2 y que tu distro está sana. Si tu base es inestable, cada paso de instalación se vuelve folclore.

Límite #1: deja de heredar el PATH de Windows automáticamente a menos que lo quieras

La rotura más sigilosa ocurre cuando WSL “amablemente” incluye rutas de Windows. De repente tu python dentro de WSL apunta a un ejecutable de Windows,
que entonces intenta leer rutas de Linux y falla de maneras creativas.

Desactívalo editando /etc/wsl.conf dentro de la distro y luego reiniciando WSL.

Límite #2: trata el sistema de archivos de WSL como tu disco de desarrollo

Coloca repositorios bajo ~ (u otra ruta Linux), no bajo /mnt/c/Users/.... Lo último te castigará en rendimiento y en casos límite de herramientas.
Si debes operar sobre archivos de Windows (cumplimiento, unidades compartidas), aisla ese flujo de trabajo y acepta que será más lento.

Ubicación del sistema de archivos: dónde vive tu código decide tu velocidad

Tus toolchains no son lentos; tu ruta de almacenamiento es lenta. Node y Python son especialmente sensibles porque crean y leen miles de archivos pequeños.
Si esos viven bajo /mnt/c, cada operación de sistema de archivos toma el camino largo a través de interoperabilidad.

La regla es sencilla:

• Código + dependencias dentro del sistema de archivos ext4 de WSL (típicamente bajo /home) para velocidad.
• Rutas montadas de Windows para intercambio ocasional de archivos, no para builds.

Cuando alguien dice “WSL es lento”, pregunto una cosa: “¿Dónde está el repo?” La mayor parte del tiempo, esa es toda la explicación.

Node.js en WSL (nvm, corepack y evitar el caos global)

Instala Node en WSL usando nvm. Me da igual si apt tiene nodejs. Me da igual si Windows ya tiene Node. Quieres versiones por usuario rápidas, repetibles,
que no choquen con paquetes del sistema o herramientas corporativas.

Política de versiones que no genera fatiga de pager

• Usa Active LTS para la mayoría de los equipos.
• Usa current solo cuando estés validando con antelación, no porque te sintieras con suerte.
• Fija la versión mayor/menor de Node en .nvmrc en la raíz del repositorio. Ese es tu contrato.

Gestores de paquetes: deja que Corepack haga su trabajo

Los setups modernos de Node a menudo usan Yarn o pnpm. Corepack viene con Node y puede instalar y fijar la versión del gestor de paquetes declarada por el proyecto.
Esto reduce los “funciona en mi máquina” porque “mi máquina” corrió Yarn 1 mientras CI corrió Yarn 3.

Las instalaciones globales de npm están bien para un conjunto pequeño de cosas (linters, scaffolding) pero prefiere binarios locales por proyecto y npx o scripts.
Las instalaciones globales se convierten en un cajón de trastos compartido sin etiquetas.

Python en WSL (pyenv, venv y dependencias compiladas)

Python es el runtime que castigará las intenciones vagas. Instala con pyenv cuando necesites múltiples versiones (las necesitas), y usa venv
por proyecto. No instales paquetes pip al azar globalmente y luego te preguntes por qué las dependencias de un proyecto sabotean a otro.

Dependencias del sistema: la parte que todos olvidan

Muchos paquetes de Python incluyen extensiones nativas (cryptography, numpy, lxml). A menudo existen wheels, pero no siempre para tu versión de Python o arquitectura.
Cuando pip compila desde código fuente, necesitas cabeceras del sistema y compiladores. Por eso el “pip install simple” a veces se convierte en instalar toolchains de C.
Esto es normal. Simplemente no es agradable.

Dos reglas que eliminan la mayoría del drama de Python

• Usa siempre un venv y mantenlo dentro del proyecto o en un directorio dedicado.
• Fija dependencias con un enfoque de lock apropiado para tu organización (requirements.txt con hashes, pip-tools, poetry, etc.). El mecanismo importa menos que la disciplina.

Go en WSL (GOVERSION, GOPATH e higiene de módulos)

Go es el menos dramático de los tres, por eso la gente se confía y hace cosas raras como desempaquetar tarballs manualmente en directorios aleatorios.
Instala Go en WSL en una ubicación predecible y mantén tus variables de entorno aburridas.

Mundo centrado en módulos

Si estás construyendo Go moderno, usa módulos. Coloca el código donde quieras (bajo tu directorio home está bien), y deja que go env te diga qué importa.
GOPATH todavía existe y afecta caches y herramientas antiguas, pero ya no es el lugar donde tu código fuente deba vivir.

Estrategia de versiones de Go

Si tu organización envía múltiples servicios en Go, eventualmente necesitarás varias versiones de Go. Puedes usar un gestor de versiones de Go, o estandarizar por trimestre.
Lo que no deberías hacer es “lo que sea que venía instalado en el portátil ese día.”

Interoperabilidad sin dolor: PATH, Git, SSH y VS Code

La configuración más limpia es: lenguajes dentro de WSL, editor en Windows, y una capa de interoperabilidad mínima entre ellos. La integración WSL de VS Code es popular porque
no pretende que el límite no exista—solo lo hace menos molesto.

Git: elige un lado y sé consistente

Usa Git dentro de WSL para repos almacenados dentro de WSL. Si usas Git de Windows en un repo dentro de WSL, te estás invitando a problemas con finales de línea y sorpresas de permisos.
Si usas Git de WSL en un repo bajo /mnt/c, probablemente tendrás problemas de rendimiento y confusión ocasional de metadatos.

Claves SSH: no las copies a lo loco

Guarda las claves dentro de WSL (~/.ssh) y protégelas con permisos adecuados. Si debes usar claves gestionadas por Windows, sé explícito sobre la estrategia del agente.
La clase de problemas “ayer funcionó” con SSH suele venir de confusión del agente a través del límite.

Broma #2: Nada envejece más rápido que una clave SSH que pegaste en un chat “solo por un minuto.”

Tres mini-historias corporativas (cómo los equipos rompen esto en la práctica)

Incidente: la suposición equivocada (herencia de PATH y el Python fantasma)

Un equipo migró un monorepo Node + Python de tamaño medio a WSL para acercarse más a Linux en producción. La gente estuvo contenta por aproximadamente una semana.
Luego CI empezó a fallar para un solo desarrollador, con errores de herramientas de Python que parecían dependencias malas. Todo el mundo hizo el baile habitual:
borrar venv, reinstalar, limpiar cachés, jurar en voz baja.

La causa raíz no fue el repo. Fue una suposición: “Si estoy en WSL, python es Python de Linux.” En esa máquina, WSL heredó el PATH de Windows,
y python.exe de Windows se estaba ejecutando primero. No siempre fallaba; fallaba cuando los scripts pasaban rutas de Linux o dependían de librerías solo disponibles en Linux.
Los mensajes de error eran engañosos porque se estaba ejecutando el intérprete equivocado.

La solución fue aburrida: desactivar la inyección del PATH de Windows en /etc/wsl.conf, reiniciar WSL y verificar la identidad del intérprete con which python
y comprobaciones con python -c. Después de eso, sus documentos de configuración incluyeron explícitamente “demuestra que tu Python es Python de Linux” como un paso obligatorio.

La lección: cuando una falla es específica de la máquina e inconsistente, sospecha del límite—PATH, ubicación del sistema de archivos, configuraciones de proxy—antes de sospechar de las dependencias.
Las dependencias son deterministas; tu entorno a menudo no lo es.

Optimización que salió mal (mover repos a /mnt/c para “simplificar backups”)

Otra organización decidió que sería “más limpio” si todo el código fuente viviera bajo el perfil de usuario de Windows para incluirlo en backups corporativos y escaneos DLP de endpoint.
Su distro WSL fue tratada como desechable. Eso sonó razonable en una reunión.

La primera queja fue instalaciones lentas: npm ci tardando una eternidad. Luego los builds de Go empezaron a ralentizarse. La creación de venv de Python se volvió lenta.
Los ingenieros empezaron a cambiar a herramientas nativas de Windows “solo por velocidad”, lo que reintrodujo el mismo lío de “dos entornos” que intentaban evitar.

Los agentes de seguridad en Windows estaban escaneando operaciones de archivos, lo que multiplicó el dolor para cargas de trabajo con “muchos archivos pequeños”. El árbol de dependencias de Node es esencialmente
un benchmark de sobrecarga del sistema de archivos, y falló el benchmark ruidosamente. El equipo intentó optimizar excluyendo directorios del escaneo, pero las excepciones de política fueron lentas,
y las exclusiones no cubrieron todos los caminos.

Eventualmente cambiaron el modelo: los repos y directorios de dependencias viven en el sistema de archivos de WSL para rendimiento; el backup se gestiona empujando hacia git remoto y,
cuando hace falta, exportando artefactos. Las preocupaciones DLP se trataron controlando qué se puede copiar fuera de WSL en lugar de castigar cada lectura/escritura.

La lección: optimizar por gobernanza moviendo cargas calientes de build al sistema de archivos de Windows es como poner tu base de datos en almacenamiento de red “por conveniencia.”
Funcionará. También será lento. Y luego la gente hará circunvalaciones que no controlas.

Práctica aburrida pero correcta que salvó el día (fijar toolchains y verificarlos)

Un equipo de plataforma soportaba docenas de servicios en Node, Python y Go. No querían laptops tipo copo de nieve. Escribieron un script bootstrap que:
instalaba paquetes base, configuraba límites de WSL, instalaba nvm/pyenv y establecía versiones por defecto. También añadieron un paso de “verificar” que imprimía versiones y rutas clave.

No fue llamativo. No usó un framework de aprovisionamiento elegante. Fue un script shell y una lista de verificación. También forzó salidas estándar: el node, python,
pip y go de todos se verificaban de la misma manera. Eso significó que los tickets de soporte empezaron con hechos, no con sensaciones.

Cuando una nueva imagen corporativa de portátil se desplegó, cambió silenciosamente el orden del PATH de Windows e introdujo un shim de Python de Windows que confundió a usuarios de WSL—en algunas máquinas.
La verificación del bootstrap lo detectó inmediatamente porque la salida no coincidía con los patrones esperados. En lugar de un mes de problemas intermitentes, fue una corrección de un día:
actualizar la guía de /etc/wsl.conf y volver a ejecutar el paso de verificación.

La lección: la práctica aburrida es “fija versiones y verifica identidad.” No una vez, sino en cada reconstrucción. Es aburrida hasta que te salva, y entonces se vuelve tu favorita.

Guía rápida de diagnóstico

Cuando “Node/Python/Go en WSL está roto” cae en tu regazo, no empieces a reinstalar cosas. Destruirás evidencia y perderás tiempo.
Diagnostica en este orden para encontrar el cuello de botella rápido.

Primero: confirma el límite (versión de WSL, PATH, ubicación del sistema de archivos)

• ¿Es esto WSL 2?
• ¿Está el repo bajo el sistema de archivos Linux o en /mnt/c?
• ¿WSL está heredando el PATH de Windows? ¿Están binarios de Windows sombreando a los de Linux?

Segundo: confirma la identidad del toolchain (qué binario, qué versión, qué método de instalación)

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

Tercero: confirma las restricciones de rendimiento (E/S, CPU, memoria, interacción con antivirus)

• Si las instalaciones/builds son lentos: comprueba si estás operando sobre /mnt/c.
• Si hay bloqueos aleatorios: revisa el espacio libre en disco y la presión de memoria dentro de WSL.
• Si las descargas de red fallan: revisa la configuración de proxy y la resolución DNS dentro de WSL.

Cuarto: solo entonces reinstala

Reinstalar sin saber qué falló es cómo terminas con tres instalaciones rotas en lugar de una.

Errores comunes: síntomas → causa raíz → solución

1) “python apunta a python.exe”

Síntomas: python se ejecuta pero no puede importar módulos de Linux; las rutas parecen C:\...; el venv se comporta de forma extraña.

Causa raíz: WSL heredó el PATH de Windows; Python de Windows está primero en la precedencia.

Solución: Desactivar la adición del PATH en /etc/wsl.conf, reiniciar WSL y verificar con which python y file $(which python).

2) “npm install tarda una eternidad”

Síntomas: npm ci o pnpm install es dramáticamente más lento que en compañeros; alto uso de CPU en procesos de seguridad de Windows.

Causa raíz: Repo o node_modules bajo /mnt/c; sistema de archivos de Windows + sobrecarga de escaneo para archivos pequeños.

Solución: Mover el repo al sistema de archivos de WSL (~/src), reinstalar dependencias y usar acceso de Windows solo para edición.

3) “pyenv install falla por falta de cabeceras”

Síntomas: Errores de compilación mencionando zlib, openssl, readline o ffi.

Causa raíz: Faltan dependencias de compilación para compilar Python.

Solución: Instalar paquetes requeridos vía apt (compilador, cabeceras dev), luego reintentar pyenv install.

4) “go get funciona, pero los builds fallan en CI”

Síntomas: El build local tiene éxito; el build en CI o en el equipo de un compañero falla; las versiones de módulos difieren.

Causa raíz: Las versiones de los módulos no están fijadas/commiteadas; go.mod/go.sum han divergido.

Solución: Ejecutar go mod tidy, commitear go.sum y establecer una versión mínima de Go en go.mod.

5) “Permiso denegado en el repo”

Síntomas: Git no puede escribir; herramientas no pueden crear archivos; desajustes extraños de UID/GID.

Causa raíz: Trabajar en el sistema de archivos montado de Windows con desajuste de metadatos de permisos; a veces opciones de montaje incorrectas.

Solución: Mover el repo al sistema de archivos de WSL; si debes usar /mnt/c, ajustar opciones de montaje y aceptar limitaciones.

6) “Terminal de VS Code muestra un Node, las tareas usan otro”

Síntomas: El terminal muestra Node 20; tareas/scripts de build se comportan como Node 18; resultados inconsistentes.

Causa raíz: Contextos mixtos: VS Code de Windows lanzando tareas en shell de Windows vs WSL; o PATH diferente entre shells de login/no-login.

Solución: Asegúrate de estar en una ventana remota WSL; asegura que la inicialización del shell cargue nvm/pyenv para shells no interactivos, o configura las tareas explícitamente.

Tareas prácticas (comandos + salidas + decisiones)

Estas son comprobaciones reales que ejecuto. Cada una tiene: un comando, qué significa la salida y la decisión que tomas a partir de ello.
Ejecútalas dentro de WSL salvo que se indique lo contrario.

Task 1: Confirmar versión de WSL y distros (desde Windows)

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

Significado: Tu distro principal es Ubuntu-22.04 y está en WSL 2.

Decisión: Si VERSION es 1, conviértela o instala una distro WSL 2. No construyas toolchains modernos en WSL 1 a menos que disfrutes de casos límite.

Task 2: Comprobar kernel y datos básicos de la distro

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

Significado: Estás en la línea de kernel WSL2; la arquitectura es x86_64.

Decisión: Si ves una arquitectura inesperada (por ejemplo, arm64), asegúrate de que tus builds y binarios coincidan.

Task 3: Detectar filtración del PATH de Windows

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

Significado: PATH empieza con toolchains del usuario Linux; no hay entradas obvias de /mnt/c/Windows en las primeras líneas.

Decisión: Si ves muchas entradas /mnt/c, desactiva la adición del PATH en /etc/wsl.conf y reinicia WSL.

Task 4: Verificar de dónde viene Node

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

Significado: Node lo proporciona nvm en tu directorio home.

Decisión: Si which node apunta a /usr/bin/node, estás usando el Node de apt. Decide si eso es aceptable; normalmente no lo es para trabajo multiversión.

Task 5: Confirmar que Node y npm son coherentes

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

Significado: Las versiones de Node y npm están alineadas para ese release de Node.

Decisión: Si npm es inesperadamente viejo/nuevo, puede haber sombreado de PATH o una instalación parcial.

Task 6: Comprobar estado de Corepack (plano de control para Yarn/pnpm)

cr0x@server:~$ corepack --version
0.24.1

Significado: Corepack existe y puede gestionar versiones de Yarn/pnpm.

Decisión: Si falta, probablemente estés en un Node más antiguo o una build personalizada; decide si actualizar Node o gestionar gestores de paquetes manualmente.

Task 7: Verificar identidad de Python y ruta del ejecutable

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

Significado: Python está controlado por los shims de pyenv (bueno para múltiples versiones).

Decisión: Si apunta a /mnt/c/... o termina en .exe, estás ejecutando Python de Windows dentro de WSL. Arregla la filtración del PATH.

Task 8: Confirmar versión de Python y desde dónde se ejecuta

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

Significado: Estás ejecutando el intérprete instalado por pyenv.

Decisión: Si sys.executable apunta a un lugar sorprendente, detente y arregla la selección de intérprete antes de tocar dependencias.

Task 9: Crear y validar un venv (prueba el aislamiento de pip)

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

Significado: Tu shell usa el intérprete del venv; las instalaciones de pip irán al venv.

Decisión: Si which python no cambia tras la activación, la inicialización de tu shell está rota o no estás activando correctamente.

Task 10: Verificar instalación y entorno de Go

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

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

Significado: Go está instalado en una ubicación estándar e informa el OS/arch correctos.

Decisión: Si informa windows/amd64, de algún modo llamaste a Go de Windows desde WSL. Eso es una violación del límite.

Task 11: Confirmar modo de módulos de Go y rutas clave

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

Significado: GOPATH está en tu home; los módulos están activos (GOMOD apunta a un go.mod); las cachés están en espacio Linux.

Decisión: Si GOMOD está vacío dentro de un repo con módulo, no estás en el directorio del módulo o el comportamiento de GO111MODULE es extraño; arregla antes de depurar dependencias.

Task 12: Detectar “el repo está en /mnt/c” (señal de alerta de rendimiento)

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

Significado: Estás construyendo desde el montaje del sistema de archivos de Windows.

Decisión: Si este repo contiene dependencias de Node o Python, muévelo a ~/src en WSL. Espera grandes mejoras de velocidad.

Task 13: Medir espacio en disco básico (fallos de instalación misteriosos adoran discos llenos)

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

Significado: Tienes ~41G libres en el sistema de archivos de la distro.

Decisión: Si estás cerca del 100%, para. Limpia cachés antes de culpar a los gestores de paquetes.

Task 14: Comprobar presión de memoria (kills aleatorios de builds y ralentizaciones)

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

Significado: La memoria disponible es baja, el swap está activo.

Decisión: Espera builds lentos. Cierra apps que consuman mucha memoria, ajusta límites de memoria de WSL o reduce el paralelismo en instalaciones/tests.

Task 15: Comprobar DNS y conectividad saliente (fallos de fetch de paquetes)

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

Significado: La resolución DNS funciona desde dentro de WSL.

Decisión: Si la resolución falla, soluciona DNS/proxy de WSL antes de tocar instaladores de lenguajes.

Listas de verificación / plan paso a paso

Plan A: configuración limpia y reproducible (recomendado)

1. Confirma WSL 2 y elige una distro.
   Usa wsl.exe -l -v. Si ves WSL 1, arréglalo primero.
2. Actualiza paquetes base.
   Ejecuta apt update/upgrade e instala build essentials. Esto evita que “pip trató de compilar algo y murió” más adelante.
3. Establece límites en /etc/wsl.conf.
   Desactiva la inyección del PATH de Windows a menos que tengas una necesidad específica.
4. Crea un workspace nativo Linux.
   Haz ~/src, clona repos allí y deja de desarrollar bajo /mnt/c.
5. Instala nvm, luego Node LTS.
   Añade .nvmrc por repo. Prefiere corepack para fijar Yarn/pnpm.
6. Instala pyenv, luego las versiones de Python que necesites.
   Establece un default global y una versión local por repo cuando sea necesario.
7. Usa venv por proyecto.
   Crea .venv, actívalo y luego instala dependencias.
8. Instala Go en una ruta estable.
   Ajusta PATH para incluir Go, verifica go env.
9. Ejecuta las tareas de verificación.
   Comprueba which y versiones para node/python/go, y verifica la ubicación del repo.
10. Automatízalo.
    Pon estos pasos en un script bootstrap y requiérelo en el onboarding.

Plan B: cuando te obligan a trabajar bajo /mnt/c (aceptable pero más lento)

1. Mantén los runtimes de lenguajes en WSL de todos modos. No instales runtimes paralelos en Windows “para acelerar”.
2. Mantén directorios pesados en dependencias fuera de /mnt/c si es posible (algunas herramientas permiten configurar caché y rutas de salida de build).
3. Espera instalaciones lentas de Node. Planea: usa lockfiles, evita instalaciones limpias repetidas y no midas WSL basándote en este modo.
4. Sé explícito sobre finales de línea y bits ejecutables; los sistemas de archivos de Windows no preservan naturalmente las semánticas de Linux.

Preguntas frecuentes

¿Debería instalar Node/Python/Go también en Windows?

Generalmente no. Instálalos en WSL. Instalarlos en Windows crea ambigüedad: editores, terminales y scripts pueden elegir runtimes diferentes.
Si necesitas builds nativos de Windows para un producto específico, aísla ese flujo y documéntalo.

¿WSL 2 siempre es mejor que WSL 1 para el desarrollo?

Para la mayoría de stacks modernos, sí. WSL 2 está más cerca del comportamiento real de Linux y suele ser mejor para contenedores y compatibilidad de herramientas.
WSL 1 puede ser útil para ciertos patrones de acceso al sistema de archivos, pero no es la elección por defecto para toolchains limpios.

¿Por qué Node es mucho más lento en algunos setups?

Porque las cargas de Node estresan el sistema de archivos: muchos archivos pequeños, operaciones frecuentes de metadata. Si tu repo está en /mnt/c,
pagas la sobrecarga de interoperabilidad además de lo que haga la herramienta de seguridad de Windows.

¿Puedo usar apt para instalar Node y Python en vez de gestores de versiones?

Puedes, pero cambiarás simplicidad hoy por dolor después cuando las versiones diverjan entre proyectos. apt está bien cuando necesitas una versión estable
y la distro proporciona lo que necesitas. La mayoría de equipos necesitan múltiples versiones. Usa nvm y pyenv.

¿Qué hay de Conda para Python?

Conda puede funcionar bien, especialmente para stacks científicos. En entornos corporativos puede también introducir su propio universo de dependencias y huella en disco.
Si tu organización ya estandariza en Conda, úsala. Si no, pyenv + venv suele ser más simple y más nativo de Linux.

¿Dónde debo almacenar mis repos Git?

Dentro del sistema de archivos Linux de WSL (por ejemplo, ~/src) para rendimiento y semánticas correctas de Linux. Usa rutas de Windows para intercambio ocasional de archivos,
no para builds pesados en dependencias.

¿Cómo mantengo mi entorno reproducible en el equipo?

Fija versiones de herramientas en el repo (.nvmrc, archivos de versión de Python, go.mod), commitea lockfiles y proporciona un script bootstrap que instale
los gestores de versiones y paquetes requeridos. Añade un paso de verificación que imprima rutas y versiones.

¿Necesito Docker si uso WSL?

No siempre. WSL te da un userland Linux útil para desarrollo. Docker añade aislamiento de runtime y paridad con producción para servicios.
Muchos equipos usan ambos: WSL para el shell del desarrollador, Docker para servicios y dependencias.

¿Cuál es la forma más segura de manejar claves SSH con WSL?

Mantén las claves en WSL bajo ~/.ssh, usa permisos estrictos y un agente SSH dentro de WSL cuando sea posible.
Evita copiar claves entre Windows y WSL a lo loco. Si la política corporativa requiere un agente de Windows, documenta la integración explícitamente.

¿Por qué veo comportamiento diferente entre sesiones de terminal?

La inicialización del shell difiere entre shells interactivos y no interactivos, login vs non-login shells, y entre aplicaciones de terminal.
Si la inicialización de nvm/pyenv vive solo en un archivo, tus herramientas pueden desaparecer en otro contexto. Estandariza la inicialización del shell.

Siguientes pasos para mantenerlo limpio

Si quieres un entorno de desarrollo WSL que no se pudra:

1. Mueve repos activos a ~/src dentro de WSL y vuelve a ejecutar instalaciones. Esto por sí solo arregla una cantidad sorprendente de quejas de “WSL es lento”.
2. Desactiva la herencia del PATH de Windows en WSL a menos que lo hayas justificado con un requisito real.
3. Adopta gestores de versiones: nvm para Node, pyenv para Python y una estrategia consistente de instalación de Go. Fija versiones por repo.
4. Escribe un script bootstrap más un script de verificación. Haz que “imprimir versiones y rutas” sea el primer paso del debugging, no el último.
5. Cuando algo falle, sigue el orden de diagnóstico: límite → identidad → rendimiento → reinstalar. No adivines.

El objetivo no es adorar la limpieza. Es hacer que tu portátil se comporte como un pequeño sistema de producción predecible: entradas controladas, límites claros
y fallos que se puedan explicar en lugar de ser místicos.