Pull to refresh

Comments 18

На одном из прошлых проектов я такое видел. ИМХО подход остро конфликтует с принципом KISS и характеризуется ключевым словом `overcomplicated`

Однако допускаю, что приму этот вариант со временем

А в чем именно конфликтует если не секрет?

А в чем именно конфликтует если не секрет?

Ваш вопрос завёл меня в некоторый тупик. Видите ли, вот всём. И когда на серьёзных щах такой вопрос задают -- зреют встречные вопросы

Однако mode собака-подозревака: off. Неужели всё описанное проще, чем:

  1. Запуск контейнеров через docker compose run --rm --service_ports? Смысл в том, что:

    1. Мы получаем интерактивную консоль, в которой без бубнов работает pdb

    2. Время запуска / остановки контейнера на глаз не отличается от локального запуска процесса

    Если вас пугает длинная команда и большое число аргументов -- вы же программист, не? Я алиасы в своё время создал в проекте, скрыв кучу аргументов и подковёрной дичи (если не знаете, докеры на разных платформах имеют свои нюансы), и с автодополнениями по табу

  2. Для remote pdb / rdb пробрасываем изнутри наружу одинаковые порты. Тогда они даже команду правильную пишут -- копипастим не включая мозг

Описанное выше нахожу на порядок более простым и идентичным локальному запуску, со всеми преимуществами локального запуска и при этом всеми преимуществами докера

Обратите внимание -- мой подход уместил в один комментарий -- настолько всё просто

Ну... Читая ваш комментарий мне отчетливо вспомнился анекдот про "но только в гамаке и стоя!". Что ж - это ваш выбор.

По поводу ваших аргументов:

  1. Когда я сосредоточен на разработке мне не очень хочется вспоминать что и как запускать, какие команды стартовать и прочее - я хочу открыть IDE и получить все плюшки сразу же, не задумываясь о том, как их в очередной раз запустить.

  2. Я могу хранить настройки проекта в гите, и он будет одинаковый везде. Если мне надо будет что-то добавить/убавить - это автоматом уедет всем разработчикам в проекте, причем самым простым для них способом - через гит

  3. Ваш подход требует определенного уровня понимания как это все работает. В описанном мною подходе порог входа ниже, так как можно просто положить все в репу и дать короткую инструкцию по запуску проекта в контейнере. А если вы считаете что разработчики все поголовно хорошо разбираются в администрировании - то вы заблуждаетесь.

Когда я сосредоточен на разработке мне не очень хочется вспоминать что и
как запускать, какие команды стартовать и прочее - я хочу открыть 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 появилась такая функциональность, как зависимые контейнеры. Я как раз планировал разобраться с этой историей и написать вторую часть статьи по этому поводу
И большое спасибо за информацию - покопаю в эту сторону

Sign up to leave a comment.