Pull to refresh

Comments 32

Вроде здорово, но такая штука должна быть покрыта тестами обязательно, иначе страшно использовать.
Посмотрел на гитхабе, тесты вроде есть, но насколько я понял они просто проверяют валидность загрузки и сохранения, а надо бы еще тестировать редактирование и добавление новых строчек.
На самом деле тесты для этого есть, но они разделены по компонентам — тесты конкретных конфигов, которые вы видели, и несколько тестов конкретных операций (изменение, добавление, удаление).
Я делал что-то похожее, bitbucket.org/eyeofhell/pyrewriter
Насколько я понял на практике, основная сложность — это задать грамматику для распарсиваемого файла, потому что после того, как все сделано и начинается работа с реальными конфигурационными файлами, «неожиданно» оказывается, что понимание грамматики автором библиотеки, автором самой программы и авторами конфигов к ней перпендикулярны друг другу :). С грамматикой достаточно тривиального конфига nginx я довольно долго промучился, печальную историю можно посмотреть в коммитах.

В связи с чем вопрос — и для каких конфигурационных файлов оно знает грамматику «из коробки»?
Не осудите за лень, скопипащу как есть из README:

Знает синтаксис (в скобках — название модуля):
BIND9 config (bind9)
Crontab (crontab)
NFS Exports (exports)
.ini (ini)
iptables-save (iptables)
nginx-like (nginx)
squid (squid)
nsd (nsd)
CSV-like space-separated values (ssv)
JSON (jsonparser)


Знает грамматику:
Ajenti (ajenti)
BIND9 DNS (bind9)
Crontabs (crontab)
Samba CTDB (ctdb)
ISC DHCPD / uDHCPD (dhcpd)
NFS /etc/exports (exports)
/etc/fstab (fstab)
/etc/group (group)
/etc/hosts (hosts)
iptables-save dump (iptables)
Netatalk afp.conf (netatalk)
NSD DNS (nsd)
/etc/passwd (passwd)
/etc/resolv.conf (resolv)
Samba (samba)
Squid 3 (squid)
Supervisord (supervisor)
Неплохо, всячески одобряю. А поиск и модификация в распарсеном конфиге по аналогу XPath есть? Чтобы если нужно поменять определенное поле и записать результат обратно не приходилось все дерево вручную перебирать?
Вручную ничего делать не нужно — достаточно вызвать config.load(), исправить нужное поле в объекте и вызвать config.save()
Рекурсивного поиска по дереву нет, но и работа с синтаксическим деревом для конечного «пользователя» не предполагается.
Наверное, я не совсем верно выразился. Есть у нас, к примеру, конфиг nginx'а с 5-ю серверами (это я к примеру, не пугайтесь). И нужно нам у сервера с именем «foo» поменять настройку с именем «bar». В конфиге список серверов, у каждого список настрек. Искать кодом по загруженному дереву сильно увеличивает количество действий для выполнения тривиальных операций. Я в своем минимальном велосипеде предусмотрел поиск вида XPath — задается строчка с указанием какие элементы интересуют — в ответ получаем один или несколько объектов, которые уже можно менять.
Мне кажется, такая функциональность не будет являться неотемлемой частью библиотеки. Можно взять любой клон LINQ to objects и использовать есть, благо объекты — самые обыкновенные
Сложный вопрос. Во всех XML парсерах XPath есть — никто для этого не использует LINQ. Но в целом тоже вариант — про LINQ для питона я не знал :).
XPath там есть из-за исключительно строгого синтаксиса XML :)
Автор, Вы меня простите, но чем Вам не нравится конфиг BIND? Один из лучших форматов конфигов, что я видел, вообще-то.
Care to explain.
Он похож на конфиг nginx, но при этом отличается точками с запятой. Похож на конфиг DHCPD, но все равно отличается. И вообще по моему личному мнению, использование YAML/XML/JSON везде-везде сэкономило бы всем кучу нервов.
Использование любого единого подхода сэкономило бы кучу нервов.
Переход с древнего формата bind'а на юный yaml, который появился, когда bind уже седой и с палочкой — потратил бы всем нервов.

Следовательно, более логичным и полезным для нервов было бы переход всего-всего как раз на формат bind. Не смотря на то, что там есть точки с запятой. В XML'е вообще стрелки, и ничего же.
Я могу объяснить. Он лучший для человека. Но если нам нужен скрипт, который зайдет на сотню серверов и поменяет настроки bind — то корректное распарсивание становится проблемой. Конечно, ее можно решить regexp, но это порождает ряд сложностей: во-первых, regexp легко писать но сложно читать — когда через полгода нужно будет что-то поменять — придется писать заного. А во-вторых, с regexp есть некие риски — в конфиге может найтись что-то неучтенное, что «неожиданно» поматчится.
Вообще-то, корректному (пусть и неполному) распарсиванию конфига посвящён Bison/YACC howto. Конфиг BIND нельзя парсить регекспами.
Как и XML.
You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the n​erves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the trangession of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of reg​ex parsers for HTML will ins​tantly transport a programmer's consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection wil​l devour your HT​ML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fi​ght he com̡e̶s, ̕h̵i​s un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo​͟ur eye͢s̸ ̛l̕ik͏e liq​uid pain, the song of re̸gular exp​ression parsing will exti​nguish the voices of mor​tal man from the sp​here I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful t​he final snuffing of the lie​s of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL I​S LOST the pon̷y he comes he c̶̮omes he comes the ich​or permeates all MY FACE MY FACE ᵒh god no NO NOO̼O​O NΘ stop the an​*̶͑̾̾​̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e n​ot rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚​N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
Оригинал
Сразу видно, вы с академическим интересом к делу подходите. К сожалению, админам и разработчикам контекстная зависимость грамматики не очень интересна — им работу делать надо. И писать интерпретатор на Bison/Yacc никто не будет. А вт использовать библиотеку на python — будет. Отсюда и начинания топикстартера.

Пассаж про регекспы не понял — я писал, что их не хотят применять из-за потенциальных проблем и поэтому используют такие штуки, как рассказал автор. Вы пересказываете мне то, что с регекспами будут проблемы. Зачем?
Писать его не надо, он уже написан. И причём много раз.
Регекспами конфиг BIND распарсить принципиально нельзя. Просто нельзя и всё, тут не идёт даже о проблемах. Проблема одна — это невозможно.
Конфиг из ада у syslog-ng
И ещё. Почему в репозитории Debian-пакетов запрещены листинги? Чтобы всем удобнее было, да?
И опять я. Выкиньте уже наконец CDBS! Иначе zомби догонят Вас и съедят мозг :)
А чем оно лучше/хуже/иначе чем Augeas, к которому прилагается 160 стоковых линз (парсеров/конструкторов конфига)?
Обидно — когда я решал здачу модификации конфигов, я потратил довольно много времени, чтобы найти существующие решения. И, не найдя, сделал свой велосипед. А тут оказывается этих существующих решений — куча. Что-то не так с моими заклинаниями поиска в гугле O_O.

С ходу могу сказать, что решение автора на чистом python, что позволяет его использовать на машинах с минимумом зависимостей и на всяких странных штуках с ARM процессорами или Windows RT. Augeas требует компиляции.
Что-то не так с моими заклинаниями поиска в гугле O_O.

Оно просто так не гуглится =). Можно выйти по ссылкам с результатов поиска по кейворду «Configuration management» на Puppet, Chef, CFEngine и т.п., и уже оттуда — на утилиты вроде Augeas.
давно не видел такого хорошего Python кода. очень приятно.
Раз пошла такая пьянка, то подскажите такого же, но например на haskell.
«На» или «для»? Если второе, то есть биндинги к Augeas. Да и язык описания линз хаскелеводу страшным не покажется.
Конечно лучше «на», import blablabla и все готово. Но любопытны любые варианты, в жизни всякое бывает.
Про «на» — не знаю, биндинги к Augeas (через FFI, насколько я понял) доступны тут: trac.haskell.org/augeas/
Sign up to leave a comment.

Articles