[devel] hasher is lacking black box properties

[devel] hasher is lacking black box properties

[Igor Vlasenko]

Господа, 
давно уже столкнулся с проблемой скриптования работы с hasher,
из за которой многие мои скрипты приватные, так как не будут 
работать в общем случае (в произвольном окружении).

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

chroot, user_a, user_b, repo_bin, repo_src
и многое другое, описывающее то, что на выходе,
зависит и от настроек hasher+hasher_priv(~/.hasher и др.)
и от дополнительных опций, проходящих через скрипт 
от пользователя к hasher'у.

И узнать эти значения сейчас скрипт не может 
без тайного знания внутренностей hasher. Т.е. сейчас 
наш hasher, к сожалению, не черный ящик.

Это поправить легко, надо только добавить к нему интерфейс
описания того, что на выходе.

Мое предложение -- опция --reportdir=/path/to/reportdir 
к hsh, и, возможно, другим утилитам.

отчеты будут локальными: каждый полезный кусок кода
может проверить, нужен ли отчет
if [ -n "$hasher_reportdir" ]; then
...
fi
и отчитаться в папке reportdir в свой отдельный файл.
т.е. формат отчета -- папка с файлами, каждый файл
либо список (srpms written, rpms written, например)
либо список значений переменных (пар ключ-значение).

Т.е. предлагаю обсудить, как будет выглядеть такой интерфейс,
если Дмитрий согласится, то написать и я могу. Главное, чтобы 
он появился в hasher.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] hasher is lacking black box properties

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Wed, Mar 02, 2011 at 05:28:57PM +0200, Igor Vlasenko wrote:
> наш hasher не является черным ящиком: вход у него есть,
> и скрипт может подать туда что-нибудь,
> а вот описания выхода ему не хватает --
> 
> chroot, user_a, user_b, repo_bin, repo_src
> и многое другое, описывающее то, что на выходе,
> зависит и от настроек hasher+hasher_priv(~/.hasher и др.)
> и от дополнительных опций, проходящих через скрипт 
> от пользователя к hasher'у.
> 
> И узнать эти значения сейчас скрипт не может 
> без тайного знания внутренностей hasher. Т.е. сейчас 
> наш hasher, к сожалению, не черный ящик.
> 
> Это поправить легко, надо только добавить к нему интерфейс
> описания того, что на выходе.
> 
> Мое предложение -- опция --reportdir=/path/to/reportdir 
> к hsh, и, возможно, другим утилитам.

Мне кажется, что и одного файла было бы достаточно, чтобы рассказать
обо всем, что может быть интересно.  Если нет, то просьба привести
контрпример.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] hasher is lacking black box properties

[Igor Vlasenko]

On Thu, Mar 03, 2011 at 02:54:46AM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 02, 2011 at 05:28:57PM +0200, Igor Vlasenko wrote:
> > наш hasher не является черным ящиком: вход у него есть,
> > и скрипт может подать туда что-нибудь,
> > а вот описания выхода ему не хватает --
[...]
> > Это поправить легко, надо только добавить к нему интерфейс
> > описания того, что на выходе.
> > 
> > Мое предложение -- опция --reportdir=/path/to/reportdir 
> > к hsh, и, возможно, другим утилитам.

> Мне кажется, что и одного файла было бы достаточно, чтобы рассказать
> обо всем, что может быть интересно.  
 
eсли давать вредные советы, то да, один большой файл, и еще 
желательно в xml, чтобы был полный ЫнтЫрпрайз :)

Сходу, как правило, в голову лезут быстрые неправильные решения. 
Я не вас критикую, я себя критикую -- в баге #, если вы 
обратили на него внимание, я вообще предлагал вам утилиту 
hsh-env. Но когда я ее написал, то увидел, что и реализация
уродлива, и, что еще хуже, уродливо ее использование 
в скриптах из-за необходимости проверять код завершения.

Немного остыв, подумал о --reportfile=file.

> Если нет, то просьба привести контрпример.

Я тогда как раз себе и привел контрпример --
в отчете нужны разные денные -- списки
(собранных пакетов, напимер) и переменные.

распишу на этом примере, какие видятся недостатки.

отчет нужен для использования в скриптах, в т.ч. в shell
скриптах. Поэтому его формат должен быть дружественным к скриптам,
по этой причине xml, ini, conf не желательны.

Но в отчете должны быть разнородные данные.
списки файлов и значения переменных.

Можно, конечно, извратиться, например, завернуть список файлов в
переменную. Но зачем извращаться, при чем недружественно к
скрипту, которому придется ее разворачивать?
Можно попытаться все завернуть в один файл, но вот при попытке 
это все развернуть в скрипте пользователя вылезет куча подводных
камней с разделителями, кавычками, квотированием и максимальной
длинной строк.

Логичнее было бы отделить мухи от котлет и хранить 
хорошие списки как текстовые списки, 
плохие списки как null-terminated string lists,
значения переменных - как угодно, но в жестко описанном
формате: например, 
<<variable_name=value.. без кавычек и экранирования, без пробелов
вокруг разделителя "=", для получения значения переменной
воспользуйтесь стандартной grep/sed или awk конструкцией>>
но для этого их придется развести по разным файлам,
отсюда и каталог отчета.

И не будет проблем с расширяемостью отчета -- старые файлы будут
следовать старым соглашениям, а не так, что пришлось добавить
кавычки или экранирование и все старые скрипты сломались.

Т.е. я считаю, что формат с каталогом отчета гораздо дружественнее
к скриптам, ради которых это все и затевается.

человеку с головой хватит и |& tee log в конце.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine