Вследствие стечения обстоятельств мне в свое время пришлось много работать в Vim, хотя изначально кодить я научился вообще в VStudio. Сейчас я пользуюсь им преимущественно для мелких задач либо в «партизанских» условиях, т.к. для оперативного решения кодинговых задач PyCharm оказался заметно юзабельнее в сочетании с большим экраном. Возможно, конечно, я просто недостаточно привык к Vim'у и не достиг в нем дзэна, но, по факту, рыночная экономика не всегда дает время удобно настроить все «под себя», особенно когда проекты меняются, а с ними и необходимые фичи в редакторе (всякие там интеграции с бд, запуск локальных конфигураций для серверов и тестов, контроль зависимостей и пр).
И IDE не навсегда
Конечно, ничто не вечно, но мне слабо представляется, что в ближайшие лет тридцать пайшармы, вебштормы и атомы полностью будут преданы забвению. Скорее наоборот, обрастут новыми фичами и будут сами кодить, управляемые встроенным ИИ (что смутно представляется в перспективах развития Vim'а).
Он есть просто везде. Был и будет. От древних юниксов, куда заходишь по ssh до современных Windows и Mac.
Ну так IDE сюда IDEально впишется.
Например, как подлить скрипты на сервер:
1. Пишем код в IDE.
2. Запускаем из нее же кастомный скриптец, который прокидывает файлы по ссх во все нужные места.
3. ???
4. PROFIT!
А если надо просто залезть поправить/почитать, то базовых знаний Vim'а более чем хватит, а вот расширять его на местах разными плагинами не всегда позволительно (секьюрити полиси, ограничения сеток и т.д.). Потому вывод: любая универсальность имеет границы, и одним Vim'ом сыт не всегда будешь.
Концепции, которые исповедуют джанга и фласк, разные. Джанга — это «out of the box» монстр, эдакий бутстрап для веб-проектов на Питоне. Фласк — это «конструктор Лего», где вы строите все с нуля из маленьких кирпичиков по мере надобности. Первый — как MacOS: все есть и гарантировано работает в пределах забора. Второй — как Gentoo: можно собрать любую ось, если есть время и желание. Первый хорош на старте, второй — для уже развернутых проектов, которым, скажем, тесно в экосистеме джанго. Подходы разные, стиль кода в проектах разный, да и подкапотная часть весьма различается.
Как вывод, не вижу профита в создании некоего котопса.
«Рано или поздно» может превратиться в долгие годы, если в вашем распоряжении скриптодактиль на овер9000 строк с запутанной логикой благодаря коллегам с не очень прямыми крыльями и «художественным» образом мышления. Мне всего лишь год назад попался проект на Django 1.6 без шансов портировать даже на 1.11, а еще за полгода до того — на Web2Py (вот где «рано или поздно» просто не случится!). Но это так, кунсткамера из веб-разработки, а были и примеры из мира деплоймент-скриптов, где одной заменой print-ов не отделаешься.
Бэкпорт я видел, но он решает только конкретные несколько вопросов. Использовать у себя, к слову, не стал, т.к. чем меньше third-party в данном случае, тем лучше.
А python-shell позиционируется как куда более универсальная обертка, которая позволит значительно разгрузить скрипты на предмет импорта и использования различных модулей.
Параметр "-p" не относится к читабельности и багам. Если ваш скрипт предусматривает его использование — используйте. Библиотеки из поста тут ни при чём — это был просто пример.
Ваша претензия интересна по нескольким пунктам, рассмотрим:
Простите, а что есть такого в shell(если это не, скажем, zsh), чего невозможно достичь в Python? Os, subprocess и иже с ними дают сносные результаты.
Если вы читали предыдущий пост о данных библиотеках, то должны знать, что python-shell и smart-env, по сути, удобные обертки над стандартными os, subprocess, а впоследствии потенциально paramiko, shutil, shlex и др. Удобство заключается в том, что девопсу (да и разработчику) не нужно заморачиваться деталями реализации тех или иных задач на Python, а также уменьшить количество повторений кода. Так что результаты там сносные, но использование библиотек из поста — это как запрашивать сущности из БД через ORM вместо запуска raw-SQL запросов.
Допустим, я захотел «пнуть»(зажечь капслед) /dev/input/event12(у меня там виртуальная клавиатура). Как это осуществить без root в python-shell? В os.popen через sudo запросто.
Заинтересуйте меня ;)
Во-первых,
Shell.sudo(*my_command_with_args) # если вы не из sudoers, то введете пароль там же
Во-вторых,
sudo myscript.py
# myscript.py
Shell.<mycmd>(*args)
# или
Shell("my-cool-cmd")(*args)
З.Ы: использование os.popen() в наше время — моветон. Об этом даже в документации Python написано.
В заключение: библиотеки развиваются, возможностей будет гораздо больше. В данный момент добавляю функционал по неблокирующим вызовам. В будущем можно будет сделать вещи вроде объединения команд через | и перенаправления >,<,>>. Но все постепенно — я за соблюдение чистоты кода, а не «накидать MVP для рынка — потом как-нибудь поправим»: с этих библиотек мне шекели не капают. :)
Жизнь — штука непредсказуемая. :)
Вообще, мне часто попадались веб-проекты, где через переменную окружения задавался режим отладки ( и это нормальное явление, имхо). Да и не только из окружения — раз источником переменных выступал key-value Консула. Получались те же Фаберже, только отдельным сервисом.
Следующим шагом захочется уметь yes/no, y/n, да/нет (ya/niht)… КМК, нужно стремиться использовать какой-то один стиль (если у вас python — логично True/False).
В smart-env стиль как раз четко очерчен: строковые константы двух видов — как в Python и как в классическом JSON (как самые потенциально ходовые).
То лаконичнее и удобнее использовать чистый shell скрипт, а не Python.
Вы вырвали фразу из контекста, причем потеряв по пути важную вторую часть.
Но добавлю по Вашему комментарию: Python может дать много возможностей, которые в Bash достигаются через боль, для манипуляций с данными + их передачей между командами Bash'а.
И потом парсить .output в python? Красиво получится, да. А если вместо предложенного варианта не использовать однострочник с list comprehension, то можно написать читаемый, понятный код.
Да, можно, но в примере с циклом Вам нужно будет прочитать больше строк кода, выполняющих то же самое, что 1-2 строчки с использованием Shell.
Библиотека должна одинаково хорошо и легко работать с любой Bash-командой (ls — это просто пример, не более), вплоть до сложных конструкций и последовательностей команд. И она будет это делать в будущих релизах.
Или, если нужно писать на питоне — выучить какой-нибудь курс «питон за 10 уроков». Писать на питоне, и испытывать сложности с dictionary… Не нужно даже пытаться.
Скорее всего, человек, которому поставлена задача смигрировать скрипты на Python, и так изучит его подобным образом. Но речь не о том, есть ли сложности со словарями или нет — вынуть переменную по ключу сможет любой хелловордщик. Если скрипт не предполагает интерпретацию значений из переменных окружения, то smart-env, вероятно, не даст ощутимой выгоды (кроме, может, как конфигурационный объект). Но с тем же успехом можно назвать Openstack «излишней сложностью», если рассматривать его в качестве площадки для поднятия вордпрессового блога на локалхосте.
Поставленную задачу (запуск процессов с параметрами и получение результатов) этот код выполняет. Зачем усложнять?
Посмотрим на Ваш пример с точки зрения качества кода:
1. Название команды само по себе не является аргументом, который следует класть в args. В Вашем примере объект, вызывающий RunMeSimple(), частично осведомлен о внутренностях вызываемой функции — явный признак того, что код надо переписать.
2. Функция возвращает кортеж из четырех (!) значений. Серьёзно? Получается, вызывающему надо будет ещё и правильно распилить полученный кортеж по переменным и, не дай Бог, не поменять stdout и stderr местами и потом гадать, почему docker ps сыпет текст в поток ошибок.
3. Возможно, я и излишне придрался к конкретному примеру, но, опять-таки, пока проект — это пара скриптов и десяток функций, то можно и subprocess дергать, а вот когда это будет мамонт на овер9000 строк — наверняка вспомните опыт других, но уже станет страшно даже чихнуть не в том месте, чтобы все не рухнуло.
Идея python-shell — это упрощение кода, а не усложнение. Ваш пример преобразовался бы в куда более понятное
cmd = Shell.mycommand(*args, env=env_from_somewhere, cwd='.')
# и где-то ниже, непосредственно там, где это нужно по логике программы
passToSomeFoo(cmd.output)
# и т.п.
причем даже без необходимости создавать под это отдельную функцию (в которой на 95.5% гарантированы копипасты блоков кода из аналогичных «функций-вызывалок»).
Вспомнилась фраза: «Это Си, тут Солнце выкатывают и закатывают вручную». Безусловно, можно продолжать городить кучи комбинаций Popen()+communicate()+<и т.д.> (втайне мечтая переехать на «новенький» 3.5 с 2.7, чтобы суметь в subprocess.run) и кушать кактус. Но зачем?
Если раньше это работало на bash — я бы хотел видеть (развидеть не смогу, знаю) ;)
Про JSON — это не портирование Bash, а новая возможность (хотя попытки ее применения, думаю, не новинка).
Про булевое значение: Вам никогда не приходилось интерпретировать значение переменной окружения на предмет того, True или не True?
# export DEBUG=True
# предположим, если переменная не выставлена, то считаем ее False
DEBUG = bool(os.environ.get('DEBUG'))
# export DEBUG=False
# export DEBUG=0
# и тут номер с невыставлением не проходит...
DEBUG = os.environ.get('DEBUG') not in ("False", "false", 0, None) # красиво?
А теперь, согласно Вашей теории, «усложнённый» вариант:
# скажем, это наш config.py
from smart_env import ENV
ENV.enable_automatic_type_cast()
DEBUG = ENV.DEBUG # и весь парсинг уже сделан за нас - в конфиге только полезная информация!
А мне больше нравится подход shellpy.
Он обсуждался на хабре.
Спасибо за ссылку, почитаю.
Да, shellpy делает код очень похожим на pure bash, и в этом одновременно плюс и минус такого подхода. Плюс в том, что код действительно можно переносить практически через Ctrl+C — Ctrl+V. Но в чем тогда резон вообще переносить всё на Python, если скрипты будут выглядеть, как «нечто похожее на Bash, но не Bash»? Я к тому, что читабельности это не добавит, а багов может даже прибавить (на тех операциях, которые в Shell делаются под капотом).
Вообще, библиотека python-shell исповедует всё-таки больше Python-овый стиль, поэтому и была сделана попытка реализовать удобное решение на базе ООП. Вспомните ORM-решения — с ними ведь обычно приятнее и быстрее работать, чем с raw-SQL, который еще и отличается в разных диалектах.
Одна из идей класса ENV — убрать лишние манипуляции с преобразованиями типов, которые неизбежны при работе с os.environ (типичный пример — проверка переменной DEBUG в окружении). Меньше отвлекающих действий — чище код. Чище код — меньше потенциальных багов. Обе библиотеки, к слову, хорошо покрываются тестами (в версии 1.0.1 почти 100% покрытие выйдет).
subprocess для задач типа ls -l избыточен, но обёртка вокруг него 5 строк займет
А теперь представьте, что вы пишете скрипт автоматизации сборки или что-то в этом роде. Ладно, если «ls» вы замените на os.listdir(), ну а если понадобится «ls -R»? ПредлОжите девопсу разместить нечто вроде такого?
[os.path.join(dp, f) for dp, dn, fn in os.walk(os.path.expanduser("~/files")) for f in fn]
Ну и аналогично насчет проверок, если команда завершилась с ошибкой и прочие прелести нештатных ситуаций.
А если 90%+ скрипта все же будет завязано на использовании Shell, потому что это просто лаконичнее и удобнее, будет ли смысл писать os.listdir() вместо Shell.ls()?
Создавая эти библиотеки, я хотел дать возможность инженерам портировать (и одновременно стабилизировать) свои Bash-скрипты без необходимости глубоко изучать Python. Но есть и обратная сторона: Python-разработчикам, в случае необходимости, также придется меньше возиться с Bash.
Выключить или игнорировать уведомления, потому что их слишком много и они слишком раздражают? Действовать вручную с риском ошибиться? Да я могу навскидку назвать сразу несколько компаний, где разбор полётов после катастрофы начинается именно с этих пунктов
Чаще всего в софтверной теме этот подход приводит только к финансовым потерям различных фигурантов проблемы. Но проблема куда глобальнее — такой подход, похоже, у человечества в крови. Далеко ходить не надо — причем первого предупреждения не хватило, и ведь тут уже не обойдешься «патчем, который по шурику разлить на машинки», да и "патч века", по сути, просто костыль на сотню лет. И хорошо бы тут сказать, что роботы спасут мир, но — их ведь тоже проектируют люди…
Ребята сделали фантик бесплатно и сидят довольные.
Не, не просто фантик. Теперь о Вондрачеке и его компании узнали в массовом порядке, и заказы от такого хайпа у него, полагаю, заметно участятся. Товарищ все четко организовал, еще и практически задаром (чуток денег на ажурные сервера и печеньки на хакатон).
пребывает в бодрствующем состоянии лишь 30 минут, а далее «засыпает»
Как-то мне понадобилось держать на Хероку целую пачку веб-ресурсов, всех объединяло одно: засыпание спустя Х минут. Таблеткой на тот момент стал, как ни странно, AWS, на котором (по другим причинам) крутилось еще пару машин. Минимальная вертушка, поднятая из предложенных free-tier, позволила решить вопрос пинга «хероковых» сайтов, так сказать, малой кровью (главное — за месячный лимит не выходить).
Тут стоит заметить, что успешная раскрутка сайта/бота/етц позволит, в конечном итоге, вообще отказаться от «пингалки» — все сделают сами юзеры.
Конечно, ничто не вечно, но мне слабо представляется, что в ближайшие лет тридцать пайшармы, вебштормы и атомы полностью будут преданы забвению. Скорее наоборот, обрастут новыми фичами и будут сами кодить, управляемые встроенным ИИ (что смутно представляется в перспективах развития Vim'а).
Ну так IDE сюда IDEально впишется.
Например, как подлить скрипты на сервер:
1. Пишем код в IDE.
2. Запускаем из нее же кастомный скриптец, который прокидывает файлы по ссх во все нужные места.
3. ???
4. PROFIT!
А если надо просто залезть поправить/почитать, то базовых знаний Vim'а более чем хватит, а вот расширять его на местах разными плагинами не всегда позволительно (секьюрити полиси, ограничения сеток и т.д.). Потому вывод: любая универсальность имеет границы, и одним Vim'ом сыт не всегда будешь.
Как вывод, не вижу профита в создании некоего котопса.
Бэкпорт я видел, но он решает только конкретные несколько вопросов. Использовать у себя, к слову, не стал, т.к. чем меньше third-party в данном случае, тем лучше.
А python-shell позиционируется как куда более универсальная обертка, которая позволит значительно разгрузить скрипты на предмет импорта и использования различных модулей.
Ваша претензия интересна по нескольким пунктам, рассмотрим:
Если вы читали предыдущий пост о данных библиотеках, то должны знать, что python-shell и smart-env, по сути, удобные обертки над стандартными os, subprocess, а впоследствии потенциально paramiko, shutil, shlex и др. Удобство заключается в том, что девопсу (да и разработчику) не нужно заморачиваться деталями реализации тех или иных задач на Python, а также уменьшить количество повторений кода. Так что результаты там сносные, но использование библиотек из поста — это как запрашивать сущности из БД через ORM вместо запуска raw-SQL запросов.
Во-первых,
Во-вторых,
З.Ы: использование os.popen() в наше время — моветон. Об этом даже в документации Python написано.
В заключение: библиотеки развиваются, возможностей будет гораздо больше. В данный момент добавляю функционал по неблокирующим вызовам. В будущем можно будет сделать вещи вроде объединения команд через | и перенаправления >,<,>>. Но все постепенно — я за соблюдение чистоты кода, а не «накидать MVP для рынка — потом как-нибудь поправим»: с этих библиотек мне шекели не капают. :)
Жизнь — штука непредсказуемая. :)
Вообще, мне часто попадались веб-проекты, где через переменную окружения задавался режим отладки ( и это нормальное явление, имхо). Да и не только из окружения — раз источником переменных выступал key-value Консула. Получались те же Фаберже, только отдельным сервисом.
В smart-env стиль как раз четко очерчен: строковые константы двух видов — как в Python и как в классическом JSON (как самые потенциально ходовые).
Вы вырвали фразу из контекста, причем потеряв по пути важную вторую часть.
Но добавлю по Вашему комментарию: Python может дать много возможностей, которые в Bash достигаются через боль, для манипуляций с данными + их передачей между командами Bash'а.
Да, можно, но в примере с циклом Вам нужно будет прочитать больше строк кода, выполняющих то же самое, что 1-2 строчки с использованием Shell.
Библиотека должна одинаково хорошо и легко работать с любой Bash-командой (ls — это просто пример, не более), вплоть до сложных конструкций и последовательностей команд. И она будет это делать в будущих релизах.
Скорее всего, человек, которому поставлена задача смигрировать скрипты на Python, и так изучит его подобным образом. Но речь не о том, есть ли сложности со словарями или нет — вынуть переменную по ключу сможет любой хелловордщик. Если скрипт не предполагает интерпретацию значений из переменных окружения, то smart-env, вероятно, не даст ощутимой выгоды (кроме, может, как конфигурационный объект). Но с тем же успехом можно назвать Openstack «излишней сложностью», если рассматривать его в качестве площадки для поднятия вордпрессового блога на локалхосте.
Посмотрим на Ваш пример с точки зрения качества кода:
1. Название команды само по себе не является аргументом, который следует класть в args. В Вашем примере объект, вызывающий RunMeSimple(), частично осведомлен о внутренностях вызываемой функции — явный признак того, что код надо переписать.
2. Функция возвращает кортеж из четырех (!) значений. Серьёзно? Получается, вызывающему надо будет ещё и правильно распилить полученный кортеж по переменным и, не дай Бог, не поменять stdout и stderr местами и потом гадать, почему docker ps сыпет текст в поток ошибок.
3. Возможно, я и излишне придрался к конкретному примеру, но, опять-таки, пока проект — это пара скриптов и десяток функций, то можно и subprocess дергать, а вот когда это будет мамонт на овер9000 строк — наверняка вспомните опыт других, но уже станет страшно даже чихнуть не в том месте, чтобы все не рухнуло.
Идея python-shell — это упрощение кода, а не усложнение. Ваш пример преобразовался бы в куда более понятное
причем даже без необходимости создавать под это отдельную функцию (в которой на 95.5% гарантированы копипасты блоков кода из аналогичных «функций-вызывалок»).
Вспомнилась фраза: «Это Си, тут Солнце выкатывают и закатывают вручную». Безусловно, можно продолжать городить кучи комбинаций Popen()+communicate()+<и т.д.> (втайне мечтая переехать на «новенький» 3.5 с 2.7, чтобы суметь в subprocess.run) и кушать кактус. Но зачем?
Про JSON — это не портирование Bash, а новая возможность (хотя попытки ее применения, думаю, не новинка).
Про булевое значение: Вам никогда не приходилось интерпретировать значение переменной окружения на предмет того, True или не True?
А теперь, согласно Вашей теории, «усложнённый» вариант:
Надеюсь, я ответил на Ваш вопрос. :)
Спасибо за ссылку, почитаю.
Да, shellpy делает код очень похожим на pure bash, и в этом одновременно плюс и минус такого подхода. Плюс в том, что код действительно можно переносить практически через Ctrl+C — Ctrl+V. Но в чем тогда резон вообще переносить всё на Python, если скрипты будут выглядеть, как «нечто похожее на Bash, но не Bash»? Я к тому, что читабельности это не добавит, а багов может даже прибавить (на тех операциях, которые в Shell делаются под капотом).
Вообще, библиотека python-shell исповедует всё-таки больше Python-овый стиль, поэтому и была сделана попытка реализовать удобное решение на базе ООП. Вспомните ORM-решения — с ними ведь обычно приятнее и быстрее работать, чем с raw-SQL, который еще и отличается в разных диалектах.
Одна из идей класса ENV — убрать лишние манипуляции с преобразованиями типов, которые неизбежны при работе с os.environ (типичный пример — проверка переменной DEBUG в окружении). Меньше отвлекающих действий — чище код. Чище код — меньше потенциальных багов. Обе библиотеки, к слову, хорошо покрываются тестами (в версии 1.0.1 почти 100% покрытие выйдет).
А теперь представьте, что вы пишете скрипт автоматизации сборки или что-то в этом роде. Ладно, если «ls» вы замените на os.listdir(), ну а если понадобится «ls -R»? ПредлОжите девопсу разместить нечто вроде такого?
Ну и аналогично насчет проверок, если команда завершилась с ошибкой и прочие прелести нештатных ситуаций.
А если 90%+ скрипта все же будет завязано на использовании Shell, потому что это просто лаконичнее и удобнее, будет ли смысл писать os.listdir() вместо Shell.ls()?
Создавая эти библиотеки, я хотел дать возможность инженерам портировать (и одновременно стабилизировать) свои Bash-скрипты без необходимости глубоко изучать Python. Но есть и обратная сторона: Python-разработчикам, в случае необходимости, также придется меньше возиться с Bash.
А в украинском и без созвучия есть таковое :)
Чаще всего в софтверной теме этот подход приводит только к финансовым потерям различных фигурантов проблемы. Но проблема куда глобальнее — такой подход, похоже, у человечества в крови. Далеко ходить не надо — причем первого предупреждения не хватило, и ведь тут уже не обойдешься «патчем, который по шурику разлить на машинки», да и "патч века", по сути, просто костыль на сотню лет. И хорошо бы тут сказать, что роботы спасут мир, но — их ведь тоже проектируют люди…
Не, не просто фантик. Теперь о Вондрачеке и его компании узнали в массовом порядке, и заказы от такого хайпа у него, полагаю, заметно участятся. Товарищ все четко организовал, еще и практически задаром (чуток денег на ажурные сервера и печеньки на хакатон).
Как-то мне понадобилось держать на Хероку целую пачку веб-ресурсов, всех объединяло одно: засыпание спустя Х минут. Таблеткой на тот момент стал, как ни странно, AWS, на котором (по другим причинам) крутилось еще пару машин. Минимальная вертушка, поднятая из предложенных free-tier, позволила решить вопрос пинга «хероковых» сайтов, так сказать, малой кровью (главное — за месячный лимит не выходить).
Тут стоит заметить, что успешная раскрутка сайта/бота/етц позволит, в конечном итоге, вообще отказаться от «пингалки» — все сделают сами юзеры.