Comments 13
Если вы планируете тестовую разработку или обучение — смело используйте WSL,
Есть же бесплатные VMware Workstation, VirtualBoox, есть Hiper-V в самой Windows... вам не нужны такие вещи, как возможность создавать снапшоты, клоны образов гостевых машин, вам не нужна безопасная песочница для тестирования софта, не нужна возможность создать надёжную виртуальную сеть, не нужен контроль за использование ресурсов вашей хост-машины?
Всё зависит от необходимых программ, а так на мой взгляд WSL вполне не плох для разработчика (для чего и задумывался), особенно в версии 2. Когда лет 6 назад с ковидом пришлось адаптировать Windows ноутбук для разработки под Linux (в офисе Linux стоял), пробовал WSL версии 1 и жить кончено было можно, но многое было неудобно, поэтому развернул в VirtualBox Ubuntu Server, запускал в headless режиме и уже подключался через Windows Terminal и в VS Code через Remote SSH. Так и жил несколько лет вполне успешно.
Потом наконец решил попробовать WSL 2 и не пожалел. Та же Ubuntu, тот же systemd и схожая настройка. Также остался Windows Terminal и VS Code (только расширение поменялось на Remote WSL). Перекрёстный доступ к файлам хоста и ВМ стал проще, гораздо более быстрый запуск, плюс как раз таки работает `code .` внутри WSL, который и открывает проект в виндовом VS Code (с полноценной виртуалкой так не работало). В качестве лайфхака - поставил docker внутри WSL именно как в обычный Linux, а не через Docker Desktop, где он работает в отдельном окружении и для работы с docker внутри WSL надо его предварительно запускать.
Вот такой опыт за 6 лет
А чем вас Docker не устраивает?
Docker всем устраивает, но из опыта разработки на Django:
разработка с тестированием в Docker: внес изменения (поменял три строчки) - собрал образ - запустил docker - потратил секунд 30.
разработка на тестовом сервере (без запуска в docker): внес изменения - запустил тестовый сервер - 2 секунды.
Только исходя из этого опыта и решил учить airflow аналогичным образом. А на чистом windows он отказывался работать корректно.
В докер компоуз файле можно настроить волум с исходниками проекта, а в среде разработки можно добавить удаленный интерпретатор Пайтон. И тогда, если приложение будет запущено в докере в режиме отладки, то при каждом объявлении файла оно будет перезапускаться. Не придется ждать сборки образа. Даже дебажить можно.
И как оно работает с интерпретатором в контейнере? Стабильно?
Как-то пробовал работать в VSCode в режиме удаленной разработки, интерпретатор был в WSL. Работало это не очень стабильно, и переход к коду библиотек, и автодополнение частенько не работали.
Что подразумевается под автодополнением? В целом работает стабильно, так, как будто действительно в Linux все, если честно сам не ожидал, а сейчас попробовал и уже привык даже, не вижу тут ничего странного ну linux в windows - ничего особенного.
блин, быстро прочитал подумал вопрос к статье)) а оказывается вопрос про запуск в контейнерах)
У меня PyCharm. Работает хорошо. Переходы, автокомплит.
Ставишь брейкпоинт в нужном месте и дебажишь. Поправил строчку, приложение перезапустилось без сборки имейжа. И так по кругу.
Я не пробовал в VS Code, но уверен, что там тоже должно работать.
Раньше использовал wsl. Хорошая штука. В vscode удобно использовать Remote WSL для подключения к линукс-среде.
Потом я дорос до того, чтобы убрать лишнюю прослойку. Теперь я счастлив на нативном гну/линуксе, но Винду пока что оставил в дуал-буте. Раз-два в год нужна для подключения к специфическим устройствам. В полевых условиях не хочется проверять взлетит ли драйвер и конкретный виндовый exe в вине|протоне.
"Распределение по умолчанию: Ubuntu"
Это надо же было так перевести!
Linux в Windows + VSC