Comments 18
На одном из прошлых проектов я такое видел. ИМХО подход остро конфликтует с принципом KISS и характеризуется ключевым словом `overcomplicated`
Однако допускаю, что приму этот вариант со временем
А в чем именно конфликтует если не секрет?
А в чем именно конфликтует если не секрет?
Ваш вопрос завёл меня в некоторый тупик. Видите ли, вот всём. И когда на серьёзных щах такой вопрос задают -- зреют встречные вопросы
Однако mode собака-подозревака: off
. Неужели всё описанное проще, чем:
Запуск контейнеров через
docker compose run --rm --service_ports
? Смысл в том, что:Мы получаем интерактивную консоль, в которой без бубнов работает
pdb
Время запуска / остановки контейнера на глаз не отличается от локального запуска процесса
Если вас пугает длинная команда и большое число аргументов -- вы же программист, не? Я алиасы в своё время создал в проекте, скрыв кучу аргументов и подковёрной дичи (если не знаете, докеры на разных платформах имеют свои нюансы), и с автодополнениями по табу
Для remote pdb / rdb пробрасываем изнутри наружу одинаковые порты. Тогда они даже команду правильную пишут -- копипастим не включая мозг
Описанное выше нахожу на порядок более простым и идентичным локальному запуску, со всеми преимуществами локального запуска и при этом всеми преимуществами докера
Обратите внимание -- мой подход уместил в один комментарий -- настолько всё просто
Ну... Читая ваш комментарий мне отчетливо вспомнился анекдот про "но только в гамаке и стоя!". Что ж - это ваш выбор.
По поводу ваших аргументов:
Когда я сосредоточен на разработке мне не очень хочется вспоминать что и как запускать, какие команды стартовать и прочее - я хочу открыть IDE и получить все плюшки сразу же, не задумываясь о том, как их в очередной раз запустить.
Я могу хранить настройки проекта в гите, и он будет одинаковый везде. Если мне надо будет что-то добавить/убавить - это автоматом уедет всем разработчикам в проекте, причем самым простым для них способом - через гит
Ваш подход требует определенного уровня понимания как это все работает. В описанном мною подходе порог входа ниже, так как можно просто положить все в репу и дать короткую инструкцию по запуску проекта в контейнере. А если вы считаете что разработчики все поголовно хорошо разбираются в администрировании - то вы заблуждаетесь.
Когда я сосредоточен на разработке мне не очень хочется вспоминать что и
как запускать, какие команды стартовать и прочее - я хочу открыть IDE и
получить все плюшки сразу же, не задумываясь о том, как их в очередной
раз запустить.
Я про алиасы кому говорил? Про автодополнения по табу кому расписывал?
А ещё, оказывается, у нас IDE много разных. Мой подход сожрёт любая -- универсальность вашего же меня огорчает
Я могу хранить настройки проекта в гите, и он будет одинаковый везде.
Если мне надо будет что-то добавить/убавить - это автоматом уедет всем
разработчикам в проекте, причем самым простым для них способом - через
гит
И заведётся во всех IDE и на всех платформах. Правда, всё так. Даже не смешно кстати.
Ваш подход требует определенного уровня понимания как это все работает. В описанном мною подходе порог входа ниже, так как можно просто положить все в репу и дать короткую инструкцию по запуску проекта в контейнере.
Я уже не в первый раз сталкиваюсь, когда невежество возносится в благодетель. Это странная тенденция.
Вообще при любом раскладе надо писать инструкцию. Именно длина инструкции определяет сложность того или иного подхода. Ваша заняла несколько экранов -- моя уместилась в комментарий. Уместите статью в размер комментария -- тогда я вам поверю.
А если вы считаете что разработчики все поголовно хорошо разбираются в администрировании - то вы заблуждаетесь.
Неужели 1 комментарий, который можно прочитать за 20 секунд -- это такая адская сложноть "администрирования" (лол. Уровень детского сада кстати). То ли дело -- 16 минут на чтение, рабочий день на настройку
Хорошо, вы можете продолжать считать ваш способ верхом совершенства. Продолжайте убеждать себя в собственной крутости 3 раза на дню =)
За сим я с вами прощаюсь, ибо быть объектом почесывания вашего ЧСВ мне неинтересно.
Продолжайте убеждать себя в собственной крутости 3 раза на дню =)
Мне казалось, я общаюсь с инженером, способным в объективные метрики.
И что в итоге? Тезис о длине (следовательно, сложности) инструкции вы проигнорировали. Тезис об универсальности вы проигнорировали. Оказывается, это "объекты почёсывания ЧСВ"
Вообще переход на личности -- верный признак неспособности оппонента вести дискуссию. За сим тоже откланиваюсь
Вроде как телеметрию можно отключить и в VSCode? Прямо пункт меню отдельный есть. Или это не совсем то?
А вот есть нюансы, некоторые дополнения можно поставить только на официальной сборке vs code, например для питона - это pylance, который технически не совсем опенсорсный емнип.
Когда-то пришлось пересесть на офиц. сборку по этой причине.
А не подскажете, почему не выбрали PyCharm? Он ведь тоже:
- Быстрый
- Удобный
- Бесплатный
- Куча плагинов
Спрашиваю, потому что сам VS Code не пробовал, руки не доходят, и пока неочевидно, почему все так его любят.
VS Code подкупает своей универсальностью, возможностью разработки в контейнере (или по SSH), и подкупает своей скоростью работы.
Много лет пользовался IDEA для java, но после VS Code она кажется тормозной...
Причем как IDE я могу сказать, что IDEA лучше - она лучше понимает контекст, у нее лучше подсказки, лучше механики рефакторинга и т.д. IDEA лучше отшлифована, если можно так сказать. Но и VS Code заметно развилась как java IDE за последний год (вернее плагин поддержки java). Так что в последнее время я предпочитаю именно VS Code как основную IDE для java.
Если же брать другие продукты JetBrains - то не могу сказать, что VS Code в чем-либо хуже. Пробовал для Go-разработки и для Rust-разработки. Но тут я начинал с VS Code и только потом пробовал JetBrains - и мне VS Code понравилась сильно больше. Но пробовал на очень небольшой промежуток, так что не могу сказать, что мнение тут полностью объективно.
В бесплатном PyCharm нет поддержки Django, нет поддержки удалённой отладки, нет отладки в контейнерах и, наверное, чего-то ещё. Хотя, может я ошибаюсь и плагинами это всё допиливается (давно не пробовал PyCharm, т.к. VS Code меня устраивает).
Единственный раз, когда PyCharm (платный) был лучше чем VS Code - удалённая разработка на FreeBSD. На VS Code она на тот момент не работала (не знаю, как сейчас).
Спасибо.
К слову скажу, что платный PyCharm (в котором весьма приятная поддержка Django) очень легко сделать бесплатным через получение License for Open Source. Я вот указал там свой репозиторий с открытым кодом (нужно, чтобы был создан более чем 3 месяца назад), написал пару комментариев в заявке, и через месяц дали лицензию на год. Даже со страной врать не пришлось. :)
Все просто - я же заходил не со стороны разработки, а со стороны админства. А в VS Code очень много плагинов не относящиеся к разработке - поддержка синтаксиса yaml, bash, json, nginx, ansible и куча всего другого.
Плюс в VS Code вы не ограничены одним языком - можно разрабатывать на разных языках в одной и той же IDE.
А вы пробовали запускать PyCharm не на топовом железе? Я как-то попробовал, не понравилось. Ни мне, ни ноуту. С VSCode таких проблем нет, он очень легкий.
Я пробовал для отладки внутри контейнеров Docker использовать Workspaces, однако не смог пофиксить видимость контейнеров внутри workspaces между собой.
В итоге остановился на debugpy внутри контейнера. А его то уже debugger, vscode без проблес "прослушивает".
Единственное пришлось делать отдельный конфиг docker-compose.dev.yml в котором отдельно ставится пакет debugpy.
Ну и launch.json тоже для докера свой.
launch.josn
{
"version": "0.2.0",
"configurations": [
{
"name":"Docker celery",
"type":"python",
"request":"attach",
"connect":{"host":"localhost","port":5678},
"pathMappings":[{
"localRoot":"${workspaceFolder}",
"remoteRoot":"."
}],
"justMyCode":true},
{
"name":"Docker Fastapi",
"type":"python",
"request":"attach",
"connect":{"host":"localhost","port":5679},
"pathMappings":[{
"localRoot":"${workspaceFolder}",
"remoteRoot":"."
}],
"justMyCode":true},
{
"name": "Fast Api",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/app/main.py",
"console": "integratedTerminal",
"envFile": "${workspaceFolder}/.env",
"env": {
"PYTHONPATH": "${workspaceFolder}/${pathSeparator}${env:PYTHONPATH}"
}
},
{
"name": "chek db",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/app/pre_start.py",
"console": "integratedTerminal",
"envFile": "${workspaceFolder}/.env",
"env": {
"PYTHONPATH": "${workspaceFolder}/backend/${pathSeparator}${env:PYTHONPATH}"
}
},
{
"name": "init data",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/app/initialiser.py",
"console": "integratedTerminal",
"envFile": "${workspaceFolder}/.env",
"env": {
"PYTHONPATH": "${workspaceFolder}/${pathSeparator}${env:PYTHONPATH}"
}
}
]
}
docker-file.dev.yml
version: "3.8"
services:
worker:
build:
context: .
dockerfile: ./Dockerfile.dev
env_file:
- .env.dev
volumes:
- ./:/usr/src/project
ports:
- "5678:5678"
api:
build:
context: .
dockerfile: ./Dockerfile.dev
env_file:
- .env.dev
volumes:
- ./:/usr/src/project
ports:
- "5679:5678"
nginx-proxy:
volumes:
- ../nginx/data/dev.conf:/etc/nginx/conf.d/default.conf
VS Code, python, контейнеры — как обуздать эту триаду и разрабатывать внутри контейнера