Комментарии 31
Фундаментальная работа. Спасибо!
А кто подскажет хорошую парсилку аргументов для скриптов на python?
Чем нативная не устраивает? docs.python.org/2/library/argparse.html
НЛО прилетело и опубликовало эту надпись здесь
Самое приличное, что я видел для питона — это verb-based парсер Argh. По сути, все что нужно сделать — взять готовые функции и навесить декораторов.
Очень круто, давно искал такой материал на русском. Спасибо!
предлагаю вам представить себе «мультитул», который умеет делать cd, ls, pwd, diff, df и ещё кучу полезных операций одной командой, только опции надо будет слегка менять (например, filesystem change, filesystem show, filesystem where итд). Будете такой пользоваться?BusyBox же, нет?
Ничего не могу сказать про него. Насколько я понял, он используется на системах с ограниченными ресурсами. На сайте BusyBox, кстати, чуть ли не сразу предлагают сделать симлинки.
В некотором смысле это похоже на программный пакет, разбитый на части постфактум. Вероятно, это неплохой тул для своих задач. Но я не уверен, что это самая удачная архитектура «на каждый день».
В некотором смысле это похоже на программный пакет, разбитый на части постфактум. Вероятно, это неплохой тул для своих задач. Но я не уверен, что это самая удачная архитектура «на каждый день».
Это всё может быть крайне неприятным и долгим делом (работа с HDD — вообще не быстрое дело).
Если нужны именно интеграционные тесты, то не очень хорошо подделывать работу с файловой системой.
Вместо HDD в любом линукс есть ram disk.
Кстати, разные файловые ситемы ведут себя по разному (Linux/MacOSX/Windows) в части игнорирования регистра имён файлов
и нормализации Unicode (MacOSX разных версий по разному его нормализуют), ну и конечно в том какие симмолы допустимы в именах.
Тут думаю ни одна библиотека по эмуляции файловой системы не поможет.
Installs painlessly
Как там в ruby в современных дистрах счас обстоят дела — 1.8 с 1.9 не конфликтует?
Соглашения по использованию опций
в unix есть биллиотека getopts, которая фактически диктует стандарт на опции.
Про getopts, вы правы, стоило сказать.
Про тесты — всё зависит от задачи. Для большинства задач fakefs всё-таки хватает. А граничные ситуации — это скорее удел юнит-тестов, нет разве? Но в целом вы правы, есть ситуации, где работать всё будет немного по-разному.
Про конфликты 1.8 и 1.9 я не знаю. Нашел, что можно поставить в спецификации гема строку:
s.required_ruby_version = Gem::Requirement.new(">= 1.9.3")
Похожая строка используется в последних рельсах, чтобы не устанавливать несовместимый гем на 1.8.
Кроме того можно для разных платформ (mswin/linux/… ) ставить разные наборы зависимостей. Так что сейчас можно сказать, что всё неплохо с разрешением этих конфликтов.
Надо сказать, что с тем, что у меня ruby 1.9 у меня проблем не было. А вот с установкой гемов по виндой — бывают, когда приходится код компилировать.
Про тесты — всё зависит от задачи. Для большинства задач fakefs всё-таки хватает. А граничные ситуации — это скорее удел юнит-тестов, нет разве? Но в целом вы правы, есть ситуации, где работать всё будет немного по-разному.
Про конфликты 1.8 и 1.9 я не знаю. Нашел, что можно поставить в спецификации гема строку:
s.required_ruby_version = Gem::Requirement.new(">= 1.9.3")
Похожая строка используется в последних рельсах, чтобы не устанавливать несовместимый гем на 1.8.
Кроме того можно для разных платформ (mswin/linux/… ) ставить разные наборы зависимостей. Так что сейчас можно сказать, что всё неплохо с разрешением этих конфликтов.
Надо сказать, что с тем, что у меня ruby 1.9 у меня проблем не было. А вот с установкой гемов по виндой — бывают, когда приходится код компилировать.
Про конфликты, у меня в ubuntu 10.04 было примерно как тут www.ruby-forum.com/topic/205477 (кстати CentOS 5.x поддерживается до 2017 года… и много где установлена)
Счас не могу поэксперементировать, т.к. поставил RVM
Счас не могу поэксперементировать, т.к. поставил RVM
Не знаю, честно говоря. Подозреваю, что сейчас это исправили: разработчики ядра и rubygems в последнее время немало работали над совместимостью и платформонезависимостью. А в том рассказе ошибка точно не из-за yum?
Нет, в том расказе… Просто если поставить пакет 1.9, то любая ruby программа, которой нужен 1.8 (их большинство в этом дистре) не установится, пока не удалим 1.9
Можно ставить из исходников, но это вовсе не лёгкий путь, учитывая что оно потом не будет обновляться не будут фиксится уязвимости, могут случиться всякие другие неприятности. А так же придётся переименовать ruby в /usr/bin/ruby1.9
Можно ставить из исходников, но это вовсе не лёгкий путь, учитывая что оно потом не будет обновляться не будут фиксится уязвимости, могут случиться всякие другие неприятности. А так же придётся переименовать ruby в /usr/bin/ruby1.9
В Ubuntu 12.04 дела гораздо лучше
apt-get install ruby
ставит 1.8
apt-get install ruby1.9.3
ставит 1.9.3
# ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
# ruby1.9.3 -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
работают вместе, но 1.9.3 нужно вызывать как ruby1.9.3
apt-get install ruby
ставит 1.8
apt-get install ruby1.9.3
ставит 1.9.3
# ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
# ruby1.9.3 -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
работают вместе, но 1.9.3 нужно вызывать как ruby1.9.3
Поправьте меня, но мне кажется не целесообразным тратить 2-3 недели на нереально четкую командную строку, работу с пайпами и прочие приблуды, если вы не собираетесь распространять свою консольную програмулинку через офф svn. Ну т.е. если число пользователей программы не перевалит за 10.
Достаточно просто приемлемого функционала и справки по --help
Достаточно просто приемлемого функционала и справки по --help
Вас же никто не заставляет следовать всем рекомендациям. Вы можете выбрать те из них, которые лучше всего подойдут в вашем случае.
Ну и помимо строки подсказки, хорошо бы следовать хотя бы соглашениям на опции.
Ну и помимо строки подсказки, хорошо бы следовать хотя бы соглашениям на опции.
Следовать соглашениям на опции это первое и главное что нужно сделать, обычно этого и достаточно.
Отчасти вы правы. Но разным приложениям нужно разное, я же не знаю, что у вас за приложение.
Мне, например, бывало полезным работать с потоками. Утилитам diff и less, наверное, нужно работать с цветами и интерактивным вводом команд. Таким крупным игрокам как gem, rspec и git зачем-то понадобились конфигурационные файлы. Держать приложение модульным и протестированным — просто правило хорошего тона. А отсутствие кодов возврата может несколько смутить человека, который вставляет вызов вашей программы в середину sh-файла, а тот и не упадет, и не завершается адекватным результатом.
Большая часть правил довольно проста в реализации, и отнюдь не занимает 3 недели, если не пытаться всё «вылизать» до идеала.
Мне, например, бывало полезным работать с потоками. Утилитам diff и less, наверное, нужно работать с цветами и интерактивным вводом команд. Таким крупным игрокам как gem, rspec и git зачем-то понадобились конфигурационные файлы. Держать приложение модульным и протестированным — просто правило хорошего тона. А отсутствие кодов возврата может несколько смутить человека, который вставляет вызов вашей программы в середину sh-файла, а тот и не упадет, и не завершается адекватным результатом.
Большая часть правил довольно проста в реализации, и отнюдь не занимает 3 недели, если не пытаться всё «вылизать» до идеала.
Нет, если распоространяете программу для широкого круга лиц, всё указанное в статье — важно.
Правильный дизайн командно-строчной программы под час не легче правильного дизайна GUI.
Правильный дизайн командно-строчной программы под час не легче правильного дизайна GUI.
Если вы тратите 2 недели на один лишь парсер командной строки, то вы пишете наверное консоль управления судьбами персонажей Санта-Барбары или что-то еще более сложное. Имея готовые парсеры командной строки, типа argparse в питоне, неприлично делать убогие параметры. На все про все уйдет времени совсем чуть-чуть. А эффект — отсутствие путаницы и возможность с одного взгляда понять, что происходит в вашей конструкции.
От себя замечу, может кому-то пригодится мой опыт.
После того как понял, что консольная тулза это прежде всего инструмент автоматизации и только во вторую очередь «молоток» для ручного применения. Исходя из этого факта пришел к выводу, что нужно выдавать не совсем в человеко-читаемом виде, а в человеко-читаемом формате, но удобном для парсинга другими тулзами. Таким форматом для меня сейчас является JSON, его применение парсинг на Python просто песня, 3-5 строки + строки на обработку исключений. При этом JSON достаточно легко читается человеком, если конечно соблюсти pretty-print.
После того как понял, что консольная тулза это прежде всего инструмент автоматизации и только во вторую очередь «молоток» для ручного применения. Исходя из этого факта пришел к выводу, что нужно выдавать не совсем в человеко-читаемом виде, а в человеко-читаемом формате, но удобном для парсинга другими тулзами. Таким форматом для меня сейчас является JSON, его применение парсинг на Python просто песня, 3-5 строки + строки на обработку исключений. При этом JSON достаточно легко читается человеком, если конечно соблюсти pretty-print.
Мне кажется текст относящийся к «заглянем под капот» должен начинаться с раздела «Общие требования».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение приложений командной строки (CLI)