M
Почему Пайчарм так не любит глобальные переменные?
Size: a a a
2020 May 05
A
M M
Почему Пайчарм так не любит глобальные переменные?
их никто не любит. Особенно в функции - обработчике асинхронных коллбеков
M
их никто не любит. Особенно в функции - обработчике асинхронных коллбеков
Как обойти тогда?
A
M M
Как обойти тогда?
не использовать глобалы
M
их никто не любит. Особенно в функции - обработчике асинхронных коллбеков
Это не обработчик коллбеков
Е
Просто представь, что ты переопределяешь PATH например, что произойдет, когда ты войдешь на сервер не из IDE?
Зачем PATH, например ты хранишь какой-нибудь токен для бота в переменных, удобно потом этого бота хранить в открытом месте для обмена опытом и прочего, также другие значения светить которые не надо.
A
M M
Это не обработчик коллбеков
да ладно?
M
да ладно?
Обработчик команды
A
M M
Обработчик команды
а команда не коллбек?
M
а команда не коллбек?
Нет команда /start
A
M M
Нет команда /start
python не знает, что такое "команда /start". В данном случае - это триггер для вызова коллбека из главного лупа для обработки поступающего сообщения с передачей самого сообщения в качестве аргумента
M
python не знает, что такое "команда /start". В данном случае - это триггер для вызова коллбека из главного лупа для обработки поступающего сообщения с передачей самого сообщения в качестве аргумента
+ Спасибо, буду практиковаться совершенствоваться!
A
plantsvszombie (9.8) увеличил карму borntohack (616.1)
A
Зачем PATH, например ты хранишь какой-нибудь токен для бота в переменных, удобно потом этого бота хранить в открытом месте для обмена опытом и прочего, также другие значения светить которые не надо.
Это понятно, но не очень правильно.
ИМХО, корректный юзкейс - это:
1. Вести разработку в GIT
2. Во время разработки использовать локальную версию кода и локальный интерпретатор с локальными переменными окружения
3. Тестирования выполняется так же локально
4. По окончании написания, и тестирования, должен быть выполнен коммит/пуш/мерж в ветку "master", которая должна посредством CI/CD (или вручную) выполнить деплой на "боевой" сервер.
5. Сам процесс "деплой" - это не только перемещение кода, но и описание его запуска, конфигурирование (в т.ч. необходимых переменных окружения), и установка всех необходимых зависимостей (с этой целью обычно pip freeze > requirements.txt из venv так же добавляют в git, а в рамках деплоя выполняют pip install -f requirements.txt)
ИМХО, корректный юзкейс - это:
1. Вести разработку в GIT
2. Во время разработки использовать локальную версию кода и локальный интерпретатор с локальными переменными окружения
3. Тестирования выполняется так же локально
4. По окончании написания, и тестирования, должен быть выполнен коммит/пуш/мерж в ветку "master", которая должна посредством CI/CD (или вручную) выполнить деплой на "боевой" сервер.
5. Сам процесс "деплой" - это не только перемещение кода, но и описание его запуска, конфигурирование (в т.ч. необходимых переменных окружения), и установка всех необходимых зависимостей (с этой целью обычно pip freeze > requirements.txt из venv так же добавляют в git, а в рамках деплоя выполняют pip install -f requirements.txt)
A
Таким образом у тебя на удаленном сервере выполняется только тот код, который заранее протестирован в той же среде
A
Нет конфликтов запуска на удаленной машине. Код выполняет интерпретатор, описанный в юните Systemd с указанием корректных переменных окружения
A
выполнение кода не зависит от доступности SSH сессии
A
а "вести кодинг, дебаг и запуск" прямо на удаленном сервере - это (ИМХО) от лукавого
Е
:-) 🤝 понятно, спасибо за разъяснение.
Пайчарм должен быть универсальным средством и удовлетворять потребности разных разработчиков и разных стратегий.
Пайчарм должен быть универсальным средством и удовлетворять потребности разных разработчиков и разных стратегий.
Е
Можно тогда глядеть в сторону докера.