[devel] Обновление numpy и matplotlib

[Ivan Zakharyaschev]

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 не смотрит во 
вложенные блоки (например, внутри условных конструкций), т.е. его 
результат -- этот толкьо приближение, а не полный список необходимых 
всегда модулей (что-то пропущено).

-- 
Best regards,
Ivan