[devel] python-module-six

[devel] python-module-six

[Alexey Shabalin]

16 апреля 2017 г., 11:30 пользователь Ivan Zakharyaschev
<imz@altlinux.org> написал:
> On Sun, 16 Apr 2017, Антон Мидюков wrote:
>
>>> >  Так вот, у меня вопрос, почему эти провайдесы у пакета не находятся? Я
>>> > >  так понял, только потому, что все эти python субмодули предоставляются >
>>> > одним файлом six.py. Все эти субмодули объявляются внутри этого скрипта. >
>>> > Т.е. скрипт поиска провайдесов такого рода провайдесы не приспособлен >
>>> > находить?
>>>
>>>  Именно так, да. При желании можно написать автоматический генератор
>>>  Provides специально для six. В каком-то смысле, это удобнее, чем
>>>  выписывать их вручную, но в это надо вложить свой труд, и неизвестно,
>>>  сколько времени это займёт. Это только приветствуется. Тут я бы ещё
>>>  обратил внимание на то, что аналогичные Provides как-то должны ещё
>>>  появляться в пакете с matplotlib, можно было бы покрыть и эти случаи
>>>  автоматическим генератором тоже:
>>>
>>>  matplotlib.externals.six.moves
>>>  matplotlib.externals.six.moves.urllib.parse
>>>  matplotlib.externals.six.moves.urllib.request
>>>
>> Я не нашёл, какие пакеты зависят от этих провайдесов, потому собрал без
>> них сегодня. И эти модули к тому же не импортируются никак, по крайней мере
>> в новой версии. Я думаю, что они уже устарели. Если это не так, поправьте.
>
>
> Вот и хорошо. Это была какая-то устаревшая некрасивая штука, и теперь мы
> выяснили, что от неё можно избавиться.
>
>>>  А ещё потом можно будет отправить на повторную сборку обновлённые
>>> пакеты,
>>>  которым их не хватило --
>>>  https://www.altlinux.org/Python3/UNMETS#six..2A_.2814.29 .
>>>
>> Ужас. Получается весь этот six состоит из одних провайдесов. Мне кажется,
>> проще переделать скрипт поиска зависимостей, чтобы зависимости типа
>> python3(six.чего-то_там) преобразовывались в зависимость на провайдес
>> python3(six). Или есть прецеденты, когда зависимости вида
>> python3(six.чего-то_там) принадлежали не пакету python3-module-six?
>
>
> Скорее, таких прецедентов нет. Но есть такое соображение:
>
> вдруг кто-то импортирует python3(six.чего-то_там), а в версии пакета six,
> собранной в Sisyphus этого нет. Тогда у пользователя, установившего этот
> пакет, может неожиданно возникнуть ошибка во время работы. Не хочется
> реагировать на такие bug-и в ручном режиме. А дописывание Provides в
> сочетании с проверкой импортируемости (как в скрипте, который я предложил
> использовать для проверки) сразу после подготовки пакета six заранее даст
> уверенность, что этих ошибок не будет. И при точечном обновлении одного или
> другого пакета у пользователя это будет отслеживаться благодаря Requires у
> пакета-клиента.
>
> Я предлагаю дописывать не такое уж большое количество Provides сразу и
> переложить заботу о работоспособности помещённых в Sisyphus пакетов на
> автоматические проверки (в тех объёмах и с той приблизительностью, которые
> реализованы), а не сталкиваться с этим при использовании. В том списке,
> который у меня записан на wiki, их совсем не много разных (10). Я этой
> простой вещи не сделал сразу, потому что хотел и автоматическую проверку
> импортируемости при сборке включить заодно (на уровне policy в
> rpm-build-python3), но был занят другими делами.
>
> Случай, который послужил началом этого обсуждения, мог бы быть тоже
> автоматически выловлен как UNMET на six.chr (или что там в точности было),
> но по-видимому этого не произошло, потому что поиск Requires не смотрит во
> вложенные блоки (например, внутри условных конструкций), т.е. его результат
> -- этот толкьо приближение, а не полный список необходимых всегда модулей
> (что-то пропущено).

Я опять наступил на грабли, что python3-module-six не провайдит все что нужно.
Вручную создал все провайдесы, и обновил пакет. Возможно я это сделал
криво. Посмотрите пожалуйста. Но наступать все время на этот пакет уже
надоело.

-- 
Alexey Shabalin