Встановлення Node, Python і Go у WSL: чисті середовища розробки без хаосу Windows

Правила: зберігайте Windows чистим, WSL — чесним

Чисте середовище розробки — це в основному відмова від «просто швидко встановити». Ви можете встановити Node на Windows, Python на Windows, Go на Windows,
потім знову встановити їх у WSL, а потім дивуватися, чому ваші інструменти випадково використовують не той двійковий файл. Це не ініціація — це запобіжувальна інцидент.

Мій упереджений стандарт:

• Встановлюйте рантайми мов усередині WSL, не на Windows. Використовуйте Windows тільки для редакторів/терміналів і опціональних GUI-інструментів.
• Користуйтеся менеджерами версій (nvm, pyenv), якщо у вас немає контрольованого монорепозиторію з фіксованими тулчейнами у контейнерах.
• Тримайте вихідний код і кеші залежностей у файловій системі Linux (всередині дистро WSL), а не під /mnt/c.
• Тримайте Windows PATH поза WSL PATH, якщо у вас немає конкретної причини інакше. Інтероперабельність — це скальпель, а не дієта.
• Автоматизуйте налаштування скриптом bootstrap і dotfiles. Якщо середовище не можна відтворити, це не середовище; це вихованець.

Цитата одна, бо вона того варта. Перефразована ідея Gene Kim: надійність походить від систем і зворотних зв’язків, а не від героїзму.
Налаштування WSL таке саме: нудні стандарти кращі за хитрі рішення.

Жарт №1: Найшвидший спосіб вивчити пріоритет PATH — зламати пріоритет PATH.
Другий за швидкістю — прочитати решту цієї статті.

Факти та історія, якими можна скористатися

Кілька стислих фактів, що пояснюють, чому WSL поводиться так, як він поводиться — і чому «легкий» шлях встановлення часто стає дорогим.

1. WSL 1 і WSL 2 — різні звірі. WSL 2 використовує справжнє ядро Linux у легковаговій VM; WSL 1 транслював Linux-виклики системи. Продуктивність і семантика різняться.
2. Мережа WSL 2 за замовчуванням за NAT. Локалхост зазвичай працює, але деякі корпоративні проксі, VPN та припущення щодо виставлення портів зрадять вас.
3. Доступ між файловими системами асиметричний. Доступ з WSL до Linux-файлової системи швидкий; доступ до Windows-файлів під /mnt/c повільніший, особливо для багатьох дрібних файлів (вітаю, node_modules).
4. Інструментарій Node став складнішим з часом. npm перетворився на платформу; Yarn і pnpm боролися за поширення; з’явився Corepack для стандартизації версій пакетних менеджерів.
5. Пакетування Python усе ще в зоні боїв. Wheels проти сборок із коду, системні бібліотеки та віртуальні середовища створюють режими відмов, що виглядають як «Python зламався», але насправді означають «вхідні дані для збірки нестабільні».
6. Go навмисно спростив складність середовища. Модулі (Go 1.11+) перемістили керування залежностями від GOPATH-центричних підходів, але GOPATH все ще важливий для кешів і старих інструментів.
7. Пакети Ubuntu віддають перевагу стабільності над свіжістю. Apt-пакети можуть відставати від релізів мов. Менеджери версій існують, бо «latest» і «secure» не синоніми.
8. Корпоративні образи Windows упереджені. Вони постачаються з Python-ланчером, старим Git і агенти безпеки, що підключаються до файлових операцій. Змішування рантаймів між Windows і WSL ускладнює відлагодження вдвічі.

Фундамент: оберіть дистро, встановіть межі та перевірте здоров’я WSL

Оберіть одне дистро WSL на «персонажа». Для більшості людей це одне Ubuntu-дистро для щоденної роботи. Кілька дистро — ок, коли потрібна ізоляція
(наприклад, одне для археології Python 2, інше для сучасних інструментів), але не створюйте десять дистро, бо не можете вирішити між shell-ами.

Санітарія версії WSL і дистро

Перш ніж встановлювати тулчейни, підтвердіть, що у вас WSL 2 і що дистро здорове. Якщо основа хитка, кожен крок встановлення перетвориться на фольклор.

Межа №1: припиніть автоматично успадковувати Windows PATH, якщо ви цього не маєте на увазі

Найпідступніші збої відбуваються, коли WSL «допомагає» і додає Windows-шляхи. Раптом ваш python у WSL вказує на Windows-екзешник,
який потім намагається читати Linux-шляхи і креативно провалюється.

Вимкніть це, відредагувавши /etc/wsl.conf всередині дистро та перезапустивши WSL.

Межа №2: сприймайте файлову систему WSL як ваш диск для розробки

Розміщуйте репозиторії під ~ (або іншим Linux-шляхом), а не під /mnt/c/Users/.... Останній спалить вас продуктивністю та хитрими поведінками інструментів.
Якщо ви мусите працювати з Windows-файлами (комплаєнс, спільні диски), ізолюйте цей сценарій і прийміть, що він буде повільнішим.

Розміщення файлової системи: де лежить код — там ваша швидкість

Ваші тулчейни не повільні; повільний шлях зберігання. Node і Python особливо чутливі, бо вони створюють і читають тисячі дрібних файлів.
Якщо вони живуть під /mnt/c, кожна файлова операція йде довгим шляхом через інтероперабельність.

Правило просте:

• Код + залежності всередині ext4-файлової системи WSL (типово під /home) для швидкості.
• Windows-монтувані шляхи для іноді потрібного обміну файлами, не для збірок.

Коли хтось каже «WSL повільний», я ставлю одне питання: «Де розташований репозиторій?» Більшість часу це вся загадка.

Node.js у WSL (nvm, corepack і як уникнути глобального хаосу)

Встановлюйте Node у WSL за допомогою nvm. Мені байдуже, що apt має nodejs. Мені байдуже, що Windows вже має Node. Ви хочете швидкі, відтворювані,
призначені для користувача версії, які не конфліктуватимуть із системними пакетами чи корпоративними інструментами.

Політика версій, що не викликає втоми від pager’ів

• Для більшості команд використовуйте Active LTS.
• Використовуйте current тільки коли ви валідуєте заздалегідь, а не тому, що пощастило.
• Фіксуйте мажор/мінор Node у .nvmrc в корені репозиторію. Це ваш контракт.

Пакетні менеджери: дайте Corepack зробити свою роботу

Сучасні Node-набори часто використовують Yarn або pnpm. Corepack постачається з Node і може встановлювати та фіксувати версію пакетного менеджера, заявлену проєктом.
Це зменшує «працює на моїй машині», бо «моя машина» запускала Yarn 1, тоді як CI запускав Yarn 3.

Глобальні npm-встановлення допустимі для невеликого набору інструментів (лінтери, scaffolding), але надавайте перевагу локальним бінарникам у проєкті та npx або скриптам.
Глобальні встановлення перетворюються на загальний безлад без ярликів.

Python у WSL (pyenv, venv і скомпільовані залежності)

Python — рантайм, який карає за невизначені наміри. Встановлюйте з pyenv, коли потрібні кілька версій (і вони потрібні), і використовуйте venv
для кожного проєкту. Не встановлюйте випадкові пакети pip глобально, а потім дивуйтеся, чому залежності одного проєкту саботують інший.

Системні залежності: частина, яку всі забувають

Багато пакетів Python містять нативні розширення (cryptography, numpy, lxml). Wheels часто є, але не завжди для вашої версії Python або архітектури.
Коли pip будує з джерел, потрібні заголовки системи та компілятори. Ось чому «просто pip install» іноді перетворюється на інсталяцію C тулчейну.
Це нормально. Просто неприємно.

Два правила, що усувають більшість драм Python

• Завжди використовуйте venv і тримайте його всередині проєкту або в окремій директорії.
• Фіксуйте залежності за допомогою підходу блокування, що підходить вашій організації (requirements.txt з хешами, pip-tools, poetry тощо). Механізм менш важливий за дисципліну.

Go у WSL (GOVERSION, GOPATH і гігієна модулів)

Go — найменш драматичний з трьох, тому люди розслабляються і роблять дивні речі, наприклад вручну розпаковують tar-болли в випадкові директорії.
Встановлюйте Go у WSL у передбачуваному місці і тримайте змінні середовища простими.

Світогляд, орієнтований на модулі

Якщо ви будуєте сучасний Go, використовуйте модулі. Кладіть код куди завгодно (під домашню директорію — нормально), і дайте go env показати, що важливо.
GOPATH все ще існує і впливає на кеші й старі інструменти, але більше не є місцем, де обов’язково має лежати ваш код.

Стратегія версій Go

Якщо в організації є кілька сервісів на Go, вам рано чи пізно знадобляться кілька версій Go. Можна використовувати менеджер версій Go або стандартизувати щоквартально.
Не робіть так: «який Go був встановлений на ноуті того дня».

Інтероперабельність без болю: PATH, Git, SSH і VS Code

Найчистіша конфігурація: мови всередині WSL, редактор на Windows і мінімальний шар інтероперабельності між ними. Інтеграція VS Code з WSL популярна, бо вона
не заперечує наявність межі — вона лише робить її менш дратівливою.

Git: оберіть одну сторону і дотримуйтеся

Використовуйте Git всередині WSL для репозиторіїв, що зберігаються в WSL. Якщо ви використовуєте Windows Git на репозиторії в WSL, ви запрошуєте проблеми з кінцями рядків і несподівані права доступу.
Якщо ви використовуєте WSL Git на репозиторії під /mnt/c, ви, ймовірно, отримаєте проблеми з продуктивністю і іноді метаданими.

SSH-ключі: не копіюйте їх без потреби

Зберігайте ключі в WSL (~/.ssh) і захищайте їх правильними правами. Якщо мусите використовувати ключі, керовані Windows, явно опишіть стратегію агента.
Клас проблем «вчора працювало» часто походить від плутанини агентів через межу.

Жарт №2: Нічого не старіє швидше, ніж SSH-ключ, який ви вставили в чат «тільки на хвилину».

Три корпоративні міні-історії (як команди це ламали)

Інцидент: неправильне припущення (успадкування PATH і фантомний Python)

Команда мігрувала середній Node + Python монорепозиторій у WSL, щоб бути ближче до Linux у продакшні. Людям було добре приблизно тиждень.
Потім CI почав падати для одного розробника, з помилками Python-інструментів, що виглядали як погані залежності. Усі виконали звичний танець:
видалити venv, перевстановити, почистити кеші, тихо поклястися.

Корінь проблеми не був у репозиторії. Це було припущення: «Якщо я в WSL, python — це Linux Python». На тій машині WSL успадкував Windows PATH,
і python.exe з Windows викликався першим. Це не завжди падало; падало, коли скрипти передавали Linux-шляхи або покладалися на Linux-специфічні бібліотеки.
Повідомлення про помилку вводили в оману, бо запускався не той інтерпретатор.

Виправлення було нудне: вимкнути додавання Windows PATH у /etc/wsl.conf, перезапустити WSL і перевірити ідентичність інтерпретатора за допомогою which python
і python -c перевірок. Після цього їхні інструкції з конфігурації явно включили «доведіть, що ваш Python — Linux Python» як обов’язковий крок.

Урок: коли відмова специфічна для машини і непослідовна, підозрівайте межу — PATH, розташування файлової системи, налаштування проксі — перед тим як підозрювати залежності.
Залежності детерміновані; ваше середовище часто — ні.

Оптимізація, що вдарила по вас (перенесення репозиторіїв в /mnt/c для «спрощення бекапів»)

Інша організація вирішила, що «чистіше», якщо весь вихідний код житиме під профілем користувача Windows, щоб його включали в корпоративні бекапи і скани DLP.
Їхнє дистро WSL вважалося тимчасовим. Це звучало розумно на нараді.

Перша скарга — повільні інсталяції: npm ci тягнеться вічно. Потім Go-збірки почали гальмувати. Створення Python venv стало повільним.
Інженери почали переходити на інструменти Windows «просто заради швидкості», що знову ввело ту саму проблему «двох середовищ», якої хотіли уникнути.

Агенти безпеки на Windows сканували файлові операції, що множило біль для робіт із великою кількістю дрібних файлів. Дерево залежностей Node по суті
стало бенчмарком файлової накладної вартості, і воно ледь витримало. Команда намагалася оптимізувати, виключаючи каталоги зі сканування, але політичні винятки були повільними,
і виключення не покривали всі шляхи.

Вони врешті-решт змінили модель: репозиторії і директорії залежностей живуть у файловій системі WSL для продуктивності; бекап обробляється через пуш у віддалений git і,
коли потрібно, експорт артефактів. Питання DLP вирішили, контролюючи, що можна копіювати з WSL, а не караючи кожне читання/запис.

Урок: оптимізація для управління, перемістивши “гарячі” збіркові навантаження на файлову систему Windows — це як поставити базу даних на мережевавий сторідж «для зручності».
Це працюватиме. Але це буде повільно. А потім люди почнуть обходити це способами, які ви не контролюєте.

Сумна, але правильна практика, що врятувала день (фіксація тулчейнів і їх перевірка)

Платформна команда підтримувала десятки сервісів на Node, Python і Go. Вони не хотіли унікальних “сніжинок” на ноутбуках. Вони написали bootstrap-скрипт, який:
встановлював базові пакети, налаштовував межі WSL, встановлював nvm/pyenv і встановлював версії за замовчуванням. Вони також додали крок «verify», що друкував версії і ключові шляхи.

Це не було ефектно. Це не використовувало модну систему провізування. Це був shell-скрипт і чекліст. Він також примушував стандартні виводи: у всіх перевіряли
node, python, pip і go однаково. Це означало, що запити на підтримку починалися з фактів, а не вражень.

Коли вийшов новий корпоративний образ ноутбука, він тихо змінив порядок Windows PATH і додав Windows-шиф для Python, що заплутував користувачів WSL — на деяких машинах.
Верифікація bootstrap виявила це одразу, бо вивід не відповідав очікуваним шаблонам. Замість місяця переривчастих проблем, це було виправлено за день:
оновили інструкцію для /etc/wsl.conf і перезапустили верифікацію.

Урок: нудна практика — «фіксуйте версії і перевіряйте ідентичність». Не раз, а під час кожного відновлення. Вона нудна, поки не врятує, а тоді стає улюбленою.

План швидкого діагностування

Коли до вас доходить повідомлення «Node/Python/Go у WSL зламався», не починайте перевстановлювати. Ви знищите докази і втратите час.
Діагностуйте в цьому порядку, щоб швидко знайти вузьке місце.

Перший крок: підтвердьте межу (версія WSL, PATH, розташування файлової системи)

• Чи це WSL 2?
• Чи репозиторій у Linux-файловій системі чи під /mnt/c?
• Чи WSL успадковує Windows PATH? Чи Windows-байнарі затінюють Linux-версії?

Другий крок: підтвердьте ідентичність тулчейна (який бінарник, яка версія, яким способом встановлено)

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

Третій крок: підтвердьте обмеження продуктивності (I/O, CPU, пам’ять, взаємодія з антивірусом)

• Якщо інсталяції/збірки повільні: перевірте, чи не працюєте ви з /mnt/c.
• Якщо випадкові зависання: перевірте вільне місце на диску та тиск пам’яті всередині WSL.
• Якщо мережеві завантаження не вдаються: перевірте налаштування проксі та розв’язування DNS у WSL.

Четвертий крок: тільки потім перевстановлюйте

Перевстановлення без розуміння причин призводить до трьох зламаних інсталяцій замість однієї.

Поширені помилки: симптом → корінь → виправлення

1) «python вказує на python.exe»

Симптоми: python запускається, але не може імпортувати Linux-модулі; шляхи виглядають як C:\...; venv поводиться дивно.

Корінь: WSL успадкував Windows PATH; Windows Python має вищу пріоритетність.

Виправлення: Вимкніть додавання PATH у /etc/wsl.conf, перезапустіть WSL, перевірте за допомогою which python і file $(which python).

2) «npm install займає вічність»

Симптоми: npm ci або pnpm install значно повільніше, ніж у колег; високе завантаження CPU у процесах безпеки Windows.

Корінь: Репозиторій або node_modules під /mnt/c; Windows-файлова система + накладні сканування для дрібних файлів.

Виправлення: Перенесіть репозиторій у файлову систему WSL (~/src), перевстановіть залежності, використовуйте Windows лише для редагування.

3) «pyenv install не вдається через відсутні заголовки»

Симптоми: Помилки збірки з посиланнями на zlib, openssl, readline або ffi.

Корінь: Відсутні системні залежності для компіляції Python.

Виправлення: Встановіть необхідні пакети через apt (компілятор, dev-заголовки), потім повторіть pyenv install.

4) «go get працює, але збірки падають у CI»

Симптоми: Локальна збірка успішна; CI або збірка колеги падає; відрізняються версії модулів.

Корінь: Версії модулів не зафіксовані/не закомічені; go.mod/go.sum розходяться.

Виправлення: Запустіть go mod tidy, закомітьте go.sum і вкажіть мінімальну версію Go у go.mod.

5) «Відмова у доступі в репозиторії»

Симптоми: Git не може писати; інструменти не створюють файли; дивні невідповідності UID/GID.

Корінь: Робота у файловій системі Windows з невідповідністю метаданих прав; іноді погані параметри монтування.

Виправлення: Перенесіть репозиторій у файлову систему WSL; якщо потрібно працювати під /mnt/c, налаштуйте опції монтування і прийміть обмеження.

6) «Термінал VS Code показує один Node, таски використовують інший»

Симптоми: Термінал показує Node 20; таски/скрипти поводяться як Node 18; результати непослідовні.

Корінь: Змішані контексти: Windows VS Code запускає таски у Windows-shell проти WSL; або PATH відрізняється між login/non-login shell.

Виправлення: Переконайтеся, що ви у WSL Remote вікні; забезпечте завантаження nvm/pyenv для неінтерактивних shell-ів або явно налаштуйте таски.

Практичні завдання (команди + виводи + рішення)

Це реальні перевірки, які я виконую. Кожна містить: команду, що означає вивід, і рішення, яке з цього випливає.
Виконуйте їх всередині WSL, якщо не зазначено інше.

Завдання 1: Перевірити версію WSL і дистро (з Windows)

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

Значення: Ваше основне дистро — Ubuntu-22.04 і воно на WSL 2.

Рішення: Якщо VERSION = 1, конвертуйте або встановіть дистро WSL 2. Не будуйте сучасні тулчейни на WSL 1, якщо ви не фанат крайніх випадків.

Завдання 2: Перевірити ядро і базові відомості дистро

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

Значення: Ви на лінії ядра WSL2; архітектура x86_64.

Рішення: Якщо бачите іншу архітектуру (наприклад arm64), переконайтеся, що ваші збірки і бінарні файли відповідають архітектурі.

Завдання 3: Виявити витік Windows PATH

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

Значення: PATH починається з Linux-користувацьких тулчейнiв; очевидних /mnt/c/Windows записів у перших рядках нема.

Рішення: Якщо бачите багато /mnt/c записів, вимкніть додавання PATH у /etc/wsl.conf і перезапустіть WSL.

Завдання 4: Перевірити, звідки береться Node

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

Значення: Node постачається nvm у вашій домашній директорії.

Рішення: Якщо which node вказує на /usr/bin/node, ви використовуєте apt-версію Node. Вирішіть, чи це прийнятно; зазвичай для багатоверсійної роботи — ні.

Завдання 5: Підтвердити сумісність Node і npm

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

Значення: Версії Node і npm відповідають релізу Node.

Рішення: Якщо npm несподівано старий/новий, ймовірно, тінь PATH або часткова інсталяція.

Завдання 6: Перевірити статус Corepack (контроль Yarn/pnpm)

cr0x@server:~$ corepack --version
0.24.1

Значення: Corepack існує і може керувати версіями Yarn/pnpm.

Рішення: Якщо відсутній, ймовірно, у вас старіший Node або кастомна збірка; вирішіть, чи оновлювати Node або керувати менеджерами пакетів вручну.

Завдання 7: Підтвердити ідентичність Python і шлях до виконуваного файлу

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

Значення: Python контролюється pyenv shims (добре для мультиверсій).

Рішення: Якщо вказує на /mnt/c/... або закінчується .exe, ви запускаєте Windows Python у WSL. Виправте витік PATH.

Завдання 8: Підтвердити версію Python і місце виконання

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

Значення: Ви запускаєте інтерпретатор, встановлений pyenv.

Рішення: Якщо sys.executable вказує кудись несподівано, зупиніться і виправте вибір інтерпретатора перед роботою з залежностями.

Завдання 9: Створити і перевірити venv (доводить ізоляцію pip)

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

Значення: Ваш shell використовує інтерпретатор venv; pip-встановлення підуть у venv.

Рішення: Якщо which python не змінюється після активації, зламано ініціалізацію shell або ви неправильно активуєте.

Завдання 10: Перевірити інсталяцію Go і середовище

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

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

Значення: Go встановлено у стандартному місці і звітує правильну ОС/архітектуру.

Рішення: Якщо звітує windows/amd64, ви якось викликали Windows Go з WSL. Це порушення межі.

Завдання 11: Підтвердити режим модулів Go і ключові шляхи

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

Значення: GOPATH у вашому домі; модулі активні (GOMOD вказує на go.mod); кеші в Linux-просторі.

Рішення: Якщо GOMOD порожній у модульному репозиторії, ви не в директорії модуля або поведінка GO111MODULE дивна; виправте перед налагодженням залежностей.

Завдання 12: Виявити «репозиторій на /mnt/c» (червоний прапорець продуктивності)

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

Значення: Ви збираєте з Windows-монту.

Рішення: Якщо в цьому репозиторії є Node або Python залежності, перенесіть його в ~/src у WSL. Очікуйте значні прискорення.

Завдання 13: Виміряти базовий простір на диску (загадкові помилки інсталяції люблять повні диски)

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

Значення: У вас ~41G вільно у файловій системі дистро.

Рішення: Якщо ви близькі до 100%, зупиніться. Очистіть кеші, перш ніж звинувачувати пакетні менеджери.

Завдання 14: Перевірити тиск пам’яті (випадкові вбивства збірок і уповільнення)

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

Значення: Доступної пам’яті мало, swap активний.

Рішення: Очікуйте повільні збірки. Закрийте пам’яттєві додатки, налаштуйте ліміти пам’яті WSL або зменшіть паралелізм для інсталяцій/тестів.

Завдання 15: Перевірити DNS і вихідні з’єднання (помилки завантаження пакетів)

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

Значення: Розв’язування DNS працює всередині WSL.

Рішення: Якщо розв’язування не працює, усуньте неполадки DNS/proxy у WSL перед тим, як чіпати інсталятори мов.

Контрольні списки / покроковий план

План A: чисте, відтворюване налаштування (рекомендовано)

1. Підтвердіть WSL 2 і оберіть одне дистро.
   Використайте wsl.exe -l -v. Якщо бачите WSL 1, виправте це спочатку.
2. Оновіть базові пакети.
   Запустіть apt update/upgrade і встановіть build essentials. Це уникне «pip намагався щось скомпілювати і помер» пізніше.
3. Встановіть межі в /etc/wsl.conf.
   Вимкніть додавання Windows PATH, якщо у вас немає конкретної потреби.
4. Створіть рідне робоче середовище Linux.
   Зробіть ~/src, клоніть репозиторії туди і припиніть розробку під /mnt/c.
5. Встановіть nvm, потім Node LTS.
   Додайте .nvmrc у кожен репозиторій. Віддавайте перевагу corepack для фіксації Yarn/pnpm.
6. Встановіть pyenv, потім потрібні версії Python.
   Встановіть глобальний дефолт і локальну версію для репозиторію, коли потрібно.
7. Використовуйте venv для кожного проєкту.
   Створіть .venv, активуйте і встановіть залежності.
8. Встановіть Go у стабільний шлях.
   Додайте Go до PATH, перевірте go env.
9. Запустіть перевірочні завдання.
   Перевірте which і версії для node/python/go, і перевірте місцерозташування репозиторію.
10. Автоматизуйте це.
    Зберіть ці кроки в bootstrap-скрипт і вимагайте його під час адаптації.

План B: коли вас змушують працювати під /mnt/c (припустимо, але повільніше)

1. Тримайте рантайми мов у WSL незалежно від усього. Не встановлюйте паралельні Windows-рантайми «щоб пришвидшити».
2. По можливості тримайте директорії з важкими залежностями поза /mnt/c (деякі інструменти дозволяють налаштувати кеш і вихідні шляхи).
3. Очікуйте повільних Node-інсталяцій. Плануйте під це: використовуйте lockfile, уникайте частих чистих інсталяцій і не оцінюйте WSL за цим режимом.
4. Будьте явними щодо кінців рядків і виконуваних бітів; файлові системи Windows не зберігають Linux-семантику природно.

Поширені запитання

Чи варто встановлювати Node/Python/Go також на Windows?

Загалом ні. Встановлюйте їх у WSL. Встановлення на Windows створює неоднозначність: редактори, термінали та скрипти можуть обирати різні рантайми.
Якщо вам потрібні Windows-нативні збірки для конкретного продукту, ізолюйте цей сценарій і задокументуйте його.

Чи WSL 2 завжди кращий за WSL 1 для розробки?

Для більшості сучасних стеків — так. WSL 2 ближчий до справжнього Linux і зазвичай кращий для контейнерів і сумісності інструментів.
WSL 1 може бути корисним для певних сценаріїв доступу до файлової системи, але це не типовий вибір для чистих тулчейнів.

Чому Node так повільний у деяких налаштуваннях?

Тому що навантаження Node сильно навантажують файлову систему: багато дрібних файлів, часті операції з метаданими. Якщо ваш репозиторій під /mnt/c,
ви платите за інтероперабельність і за те, що робить Windows-інструмент безпеки.

Чи можна використовувати apt для встановлення Node і Python замість менеджерів версій?

Можна, але ви обміняєте простоту сьогодні на біль завтра, коли версії розійдуться між проєктами. apt підходить, коли потрібна одна стабільна версія
і дистро надає те, що треба. Більшість команд потребують кілька версій. Використовуйте nvm і pyenv.

А що з Conda для Python?

Conda може добре працювати, особливо для наукових стеків. У корпоративних середовищах вона також може запровадити власну екосистему залежностей і великий дисковий слід.
Якщо ваша організація вже стандартизована на Conda — використовуйте її. Якщо ні, pyenv + venv зазвичай простіше і ближче до Linux.

Де зберігати Git-репозиторії?

Всередині Linux-файлової системи WSL (наприклад, ~/src) для продуктивності і коректної Linux-семантики. Використовуйте Windows-шляхи для рідкого обміну файлами,
але не для збірок з великою кількістю залежностей.

Як зберегти відтворюваність середовища в команді?

Фіксуйте версії інструментів у репозиторії (.nvmrc, файли версій Python, go.mod), комітьте lockfiles і надайте bootstrap-скрипт, який
встановлює менеджери версій і потрібні пакети. Додайте крок перевірки, що друкує шляхи і версії.

Чи потрібен Docker, якщо я використовую WSL?

Не завжди. WSL дає Linux-userland, достатній для розробки. Docker додає ізоляцію рантайму і паралельність з продакшн-поведінкою сервісів.
Багато команд використовують обидва: WSL для робочого shell, Docker для сервісів і залежностей.

Який безпечний спосіб працювати з SSH-ключами у WSL?

Тримайте ключі в WSL під ~/.ssh, використовуйте суворі права і по можливості агент SSH всередині WSL.
Уникайте копіювання ключів між Windows і WSL без потреби. Якщо політика вимагає Windows-агента, задокументуйте інтеграцію чітко.

Чому я бачу різну поведінку між термінальними сесіями?

Ініціалізація shell відрізняється між інтерактивними і неінтерактивними shell-ами, login vs non-login shell, і між додатками терміналу.
Якщо ініціалізація nvm/pyenv знаходиться тільки в одному файлі, ваші інструменти можуть зникати в іншому контексті. Уніфікуйте ініціалізацію shell.

Наступні кроки, що зберігають порядок

Якщо ви хочете WSL-середовище розробки, яке не розсипається:

1. Перенесіть активні репозиторії в ~/src всередині WSL і перезапустіть інсталяції. Це самостійно вирішує багато скарг «WSL повільний».
2. Вимкніть успадкування Windows PATH у WSL, якщо ви не можете обґрунтувати його необхідність.
3. Прийміть менеджери версій: nvm для Node, pyenv для Python і послідовну стратегію інсталяції Go. Фіксуйте версії в репозиторії.
4. Напишіть bootstrap-скрипт і скрипт верифікації. Зробіть «надрукувати версії і шляхи» першим кроком налагодження, а не останнім.
5. Коли щось ламається, дотримуйтеся порядку діагностики: межа → ідентичність → продуктивність → перевстановлення. Не здогадуйтеся.

Мета не в поклонінні чистоті. Мета — зробити ваш ноутбук поведінковим як невелика, передбачувана продакшн-система: контрольовані входи, чіткі межі
і відмови, що пояснюються, а не містичні.